Virtual machines

A running hypervisor comprises the hypervisor microkernel and its virtualization library (libmod_qvm.a), and one or more instances of the virtual machine process (qvm).

What is a virtual machine?

In a QNX Hypervisor environment, every virtual machine (VM) is a qvm process instance. The qvm process is an OS process that runs in the hypervisor host, outside the kernel. Each instance has an identifier marking it so that the microkernel knows that it is a qvm process.

If you remember anything about VMs, remember that from the point of view of a guest OS, the VM hosting that guest is hardware. This means that, just as an OS running on a physical board expects certain hardware characteristics (architecture, board-specifics, memory and CPUs, devices, etc.) an OS running in a VM expects those characteristics: the VM in which a guest will run must match the guest's expectations.

When you configure a VM, you are assembling a hardware platform. The difference is that instead of assembling physical memory cards, CPUs, etc., you specify the virtual components of your machine, which a qvm process will create and configure according to your specifications.

The rules about where things appear are the same as for a real board:

Don't install two things that try to respond to the same physical address.
The environment your VM configuration assembles must be one that the software you will run (the guest OS) is prepared to deal with.

The hardware analogy works in the other direction as well. A VM doesn't need to know what its guest is doing any more than hardware needs to know what an OS is is doing. In fact, the VM can't know what a guest is doing (“the guest is a blob”).

For more information about configuring VMs, see “Assembling and configuring VMs” in the “Configuration” chapter.

qvm services

Each qvm process instance provides key hypervisor services.

VM startup

In order to create the virtual environment in which a guest OS can run, a qvm process instance does the following when it starts:

Reads, parses and validates VM configuration files (*.qvmconf) and configuration information input with the process command line startup, exiting if the configuration is invalid and printing a meaningful error message to a log.
Sets up intermediate stage tables (ARM: Stage 2 page tables, x86: Extended Page Tables (EPT)).
Creates (assembles) and configures its VM, including:
- allocates RAM (r/w) and ROM (r only) to guests
- provisions a thread for every virtual CPU it presents to the guest
- provisions passthrough devices to make them available to the guest
- defines and configures virtual devices (vdevs) for the hosted guest

VM operation

During operation a qvm process instance does the following:

Traps outbound and inbound guest access attempts and determine what to do with them (i.e., if the address is to a vdev, invoke the vdev code (guest exit, then guest entrance when the vdev code completes); if the address is indeed out of bounds, treat it as such).
Saves its guest's context before relinquishing a physical CPU.
Restores its guest's context before putting the guest back into execution.
Looks after any fault handling.
Performs any maintenance activities required to ensure the integrity of the VM.

Manage guest contexts

In a virtualized environment, it is the responsibility of the CPU virtualization extensions to recognize from a guest's actions when the guest needs to exit. When a CPU triggers a guest exit, however, it is the qvm process instance (i.e., the VM) hosting the guest that saves the guest's context. When the guest has completed its task and is ready to re-enter, the process instance restores the guest's context.

Manage privilege levels

The qvm process instances manage privilege levels at guest entrances and exits, to ensure that guests can run, and that the system is protected from errant code.

On a guest entrance, the qvm process instance asks the CPU to give the guest the privilege levels it needs to run, but no more. On a guest exit, the qvm process instance asks the CPU to return to the privilege levels it requires to run in the hypervisor host.

Only the CPU hardware can change privilege levels. The qvm process performs the operations required to have the CPU change privilege levels. This mechanism (hence the operations) is architecture-specific.

Guest access to virtual and physical resources

Each qvm process instance manages its hosted guest's access to both virtual and physical resources.

When a guest attempts to access an address in its guest-physical memory, this access can be one of the following, and the qvm process hosting the guest checks the access attempt and responds as described:

Permitted: The guest is attempting to access a memory region that it owns.; The qvm process instance doesn't do anything.
Pass-through device: The guest is attempting to access memory assigned to a physical device, and the guest's VM is configured to know that the guest has direct access to this device.; The qvm process instance doesn't do anything. The guest communicates directly with the device.
Virtual device: The guest is attempting to access an address that is assigned to a virtual device (either virtual or para-virtual).; The qvm process instance requests the appropriate privilege level changes, and passes execution on to its code for the requested device. For example, a guest CPUID request triggers the qvm process instance to emulate the hardware and respond to the guest exactly as the hardware would respond in a non-virtualized system.
Fault: The guest is attempting to access memory for which it does not have permission.; The qvm process instance returns an appropriate error to the guest.

The above are for access attempts that go through the CPU. DMA access control is managed by the SMMU manager (see “DMA device containment (smmuman)”).