Priority-based scheduling

Hypervisor thread priorities and guest thread priorities

Just as with any advanced software system, to properly configure scheduling priorities in a system with a QNX Hypervisor requires a thorough understanding both of your system requirements and of your system's capabilities.

To begin with, you should keep in mind the following:

• The hypervisor host has no knowledge of what is running in its VMs, or how guests schedule their own internal software. When you set priorities in a guest OS, these priorities are known only to that guest.
• Virtual CPUs (vCPUs) are scheduled by qvm vCPU scheduling threads; these threads exist in the hypervisor host domain.
• Thread priorities in guests have no relation to thread priorities in the hypervisor host. The relative priorities of the qvm process vCPU scheduling threads determine which vCPU gets access to the pCPU.

The figure below illustrates that priorities inside guests are relevant only inside the guest and have no effect on which of two competing guests gets access to pCPUs. The shaded areas show which one of two competing vCPU threads gets access to the pCPU.

Figure 1. The significant priority for access to a pCPU is the priority of the qvm process's vCPU thread.

If two vCPUs compete for a single physical CPU (pCPU), the vCPU thread with the higher priority gets access to the pCPU immediately. The priority of the thread running inside a guest has no effect on this access. In the example shown above:

• The thread in Guest 1 has a higher priority than the thread in Guest 0.
• The hypervisor thread providing the vCPU for Guest 0 has a higher priority (200) than the hypervisor thread providing the vCPU for Guest 1 (100).
• Therefore, the internal Guest 0 thread gets access to the pCPU and runs.
• The internal Guest 1 thread is blocked until the thread in Guest 0 voluntarily blocks.

In short, the determining priority is the priority of the qvm process's vCPU scheduling thread.

Guest exits

The following cause a guest to exit:

• a halt in the guest
• a vdev access; this sort of exit doesn't necessarily cause the guest to give up control of the CPU, because the guest's vCPU thread doesn't necessarily block
• an interrupt on the host (including inter-processor interrupts (IPIs))
• a virtual timer, such as a vdev emulating an Intel 8254 chip
• an instruction, such as a CPUID instruction