Hi Quinn, Thank you for clarifying the difference between Virtualization.framework and Hypervisor.framework, and for confirming that another userspace process cannot retain or acquire the original vCPU execution resources after their owner terminates. I understand that QEMU-specific thread and process management is our responsibility, and we're examining that separately. I have one remaining question about Hypervisor.framework itself, independent of QEMU's implementation: When the process owning a Hypervisor.framework VM has actually terminated, and its supervising parent obtains terminal status through waitpid() (WIFEXITED or WIFSIGNALED), is it a supported guarantee that every vCPU executed by that process has already ceased executing guest instructions and cannot resume? This includes abnormal process termination while a thread was executing hv_vcpu_run(). I'm deliberately distinguishing irreversible cessation of guest execution from complete VM resource reclamation. I am not asking whether sending SIGKILL guarantees immediate termination, only what is established once actual process termination has been confirmed. If Hypervisor.framework provides no documented guarantee for that ordering, confirmation of that limitation would also be helpful. Thanks again for your guidance. Gary

Hi Quinn, Thank you for the detailed clarification. That's extremely helpful. The behaviour you've described addresses several of our concerns about provider crashes. There are three remaining questions concerning a fail-closed design: Provider suspension: If an NEFilterDataProvider remains alive but stops processing callbacks, is there a documented timeout or system-enforced mechanism that prevents unresolved flows from proceeding? Outstanding permissions: If the provider has previously issued a partial flow allowance using passBytes and subsequently crashes or becomes unresponsive, can already-authorised bytes continue to pass? Existing connections: You've confirmed that previously allowed flows continue after a provider crash. Is there a supported mechanism for an independent process to terminate or fence those existing flows, and positively verify that transmission has stopped? Our objective is to establish a security boundary that remains effective following failure of the application or its monitoring components. We're particularly interested in distinguishing guaranteed, documented system behaviour from behaviour that requires application-level integration testing. Thanks again for your help. Gary

Hi Quinn, Thank you for the detailed explanation and for suggesting an enhancement request. I've now submitted Feedback Assistant request FB25189315, covering persistent VM identity, independently verifiable teardown completion following host-application failure, and supported external termination where appropriate. Your clarification about the absence of a guaranteed cleanup timeline and a successor-process verification API was particularly helpful in identifying the limitation. Thanks again for your assistance.

Thank you, Quinn. That's very helpful. I have one follow-up regarding the completion of that cleanup. On an Apple Silicon Mac running macOS 26.6, if a Virtualization.framework application's termination has been independently confirmed, is there a supported lifecycle event or ordering guarantee that establishes when its guest has actually ceased executing? Specifically, is there any externally observable condition that another process can rely upon before starting a replacement VM? Or should developers treat guest cleanup completion after unexpected application termination as unobservable through the public APIs? I'm trying to distinguish confirmed application termination from confirmed guest teardown, without relying on private helper-process identities or the absence of guest telemetry. Thanks again for your guidance.