Quiescing devices during guest shutdown

When a guest shuts down, in either a controlled or uncontrolled shutdown, the qvm process should try to quiesce any physical devices used by the guest. This ensures that the guest driver doesn't continue writing to physical memory, which can leave the hardware in an unexpected or even damaged state.

When a guest shuts down and hence, its device drivers go away, the host hardware can't be expected to stay in the same state because the devices may be operating asynchronously (e.g., doing DMA writes, generating interrupts). To protect the integrity of the hardware, the qvm process in which the guest runs can be designed to quiesce any such device (i.e., make it go dormant) when the guest terminates.

To follow this design, the qvm process can include a vdev that quiesces devices and configure this vdev so its callback function is run when the qvm process terminates, before the resources of driver processes are released. The callback function must do any required cleanup, including quiescence. This entails turning off any active device as quickly as possible so that when the qvm process goes away, the device no longer:
  • writes to physical memory (very dangerous)
  • generates interrupts (less dangerous because the hypervisor can acknowledge the IRQ and ignore it)

For information on defining a vdev's control function to register a callback that runs during process shutdown, see Handling a qvm termination.

Note:
A guest can try to quiesce a device; it's just that the hypervisor can't depend on the guest doing so. For the non-safety QNX Hypervisor product, it is recommended but not required to provide a vdev to quiesce physical devices during shutdown.
Page updated: