Thanks for the reply. The use case is a security-sensitive execution system that runs a potentially faulty or unresponsive workload inside a Linux VM on Apple Silicon. The host process remains the trusted control plane. The important property for us is that the guest must not be able to retain execution or resource authority indefinitely after the host has decided that the execution is no longer valid. We therefore need to understand the guarantees provided by Virtualization.framework itself, rather than relying only on experimentally observed behavior. More specifically, assume a VZVirtualMachine is running and the guest becomes completely unresponsive — for example, its kernel is hung or stuck in a non-cooperative execution state. From the host side, we then request that the VM stop. We are trying to determine: Does Virtualization.framework provide a supported host-controlled mechanism that guarantees termination of the VM even if the guest does not cooperate? After that operation reports completion/success, is the guest guaranteed to no longer execute on any virtual CPU? Is there any documented case where guest execution could continue indefinitely after the host has requested the strongest supported stop/termination operation? Does this guarantee depend on guest cooperation, or is enforcement entirely outside the guest? If the normal stop API cannot provide such a guarantee, is there another supported Virtualization.framework lifecycle operation intended for this use case? We do not need a timing guarantee such as “termination occurs within X milliseconds.” The key requirement is whether the framework provides a host-enforced eventual termination guarantee independent of guest cooperation. Environment: macOS 26.5.1, Apple Silicon. I hope this explains the reason behind the question. I’m specifically trying to understand the supported Virtualization.framework contract, not undocumented or experimentally observed behavior.