Title: Hypervisor.framework — vCPU cessation guarantee after VM-owning process termination

Title: Hypervisor.framework — vCPU cessation guarantee after VM-owning process termination

Hello,

I'm investigating the failure-containment guarantees of Hypervisor.framework on Apple Silicon, specifically for an application that uses QEMU's HVF accelerator.

In the QEMU 11.1.2 ARM64 implementation:

• hv_vm_create() creates the VM within the QEMU process.
• Each vCPU is created and executed on a QEMU pthread using hv_vcpu_create() and hv_vcpu_run().
• No separate userspace VM-execution helper was identified in the reviewed execution path.

The security requirement is to establish guest-execution cessation independently when the VM-owning application fails.

My primary question:

If a supervising parent successfully observes that the QEMU process has actually terminated through waitpid() — whether normally or following SIGKILL — is that a supported guarantee that every Hypervisor.framework vCPU belonging to that process has ceased guest execution and cannot resume?

I am specifically asking about irreversible cessation of guest execution, not necessarily completion of all VM resource reclamation.

A few related questions:

1. Does an EVFILT_PROC/NOTE_EXIT notification establish the same guarantee, and is there a documented ordering relationship between that notification and cessation of all associated vCPUs?

2. If a thread is executing hv_vcpu_run() when its process receives SIGKILL or SIGSTOP, what cessation or suspension guarantees apply?

3. Is there a documented upper bound for cessation following process termination, or could kernel/framework blockage delay it without a specified bound?

4. Can any other userspace process retain or acquire resources allowing those vCPUs to continue executing after the original owner has terminated?

5. If the original supervising parent also crashes, is there a supported mechanism for a successor controller to obtain equivalent positive evidence of termination and vCPU cessation for the original execution instance?

The distinction between a process merely receiving a termination request and the operating system confirming actual process termination is important here.

I'm trying to establish which guarantees are supported by the framework rather than relying on experimental observations or assumptions about kernel cleanup.

Any clarification would be greatly appreciated.

Thanks, Gary