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 the 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 creating a custom vdev, see the Virtual Device Developer's Guide. For information on defining the vdev's control function to register a callback that runs during process shutdown, see “Handling a qvm termination”.

Warning: A guest can try to quiesce a device; it's just that the hypervisor can't depend on the guest doing so. When running the QNX Hypervisor for Safety variant, you must provide a vdev to quiesce physical devices during shutdown. For the non-safety QNX Hypervisor variant, this is recommended but not required.