Confidential guest reset on QEMU hypervisor: Design choices and approach

Looking at the release notes or changelogs for QEMU upstream, you might notice that there's something new in version 11.0:

SEV-SNP and TDX machines can now be reset.

This is a feature we at Red Hat helped implement. The motivations and associated challenges have been explained in detail in a FOSDEM 2026 presentation. Before this feature was available, some confidential guests (AMD SEV-based guests) could be reset normally like other non-confidential guests. Other confidential guests (like TDX, SEV-ES and SEV-SNP guests) would terminate if a reset was attempted (for example, when you initiate a reboot from the guest, or using the QEMU machine protocol command-line). 

AMD SEV guests only implement memory encryption through the secure processor, whereas SEV-ES, SEV-SNP (AMD) and TDX (Intel) guests also encrypt CPU register states in their private memory region (except those needed for VMGEXIT/TDVMCALL calls). Once these confidential guests are initialized and booted, their initial boot state is immutable and cannot be changed by the host or hypervisor.

A modern operating system (OS) implements resets of various kinds that are hardware assisted actions. For example, Linux implements OS resets through ACPI or EFI or PCI. In a virtualized environment, the hypervisor plays the role of emulating the physical hardware and therefore must assist in the guest reset process. To do so, the hypervisor needs access to the CPU registers that are part of the encrypted VMCB (AMD) or VMCS (Intel) region of the guest memory. For SEV-ES, SEV-SNP and TDX guests, this is not allowed, so the hypervisor must terminate the guest. 

This article describes a couple of options for overcoming the above described technical obstacles in implementing SEV-SNP/TDX guest resets. We then discuss the option we chose and why. Finally, it addresses future challenges that resettable confidential guests pose.

Implementing confidential guest reset

As described above, because the hypervisor must be involved in the reset process, one obvious choice is to implement the steps of a confidential guest reset entirely within KVM. KVM is the virtual machine accelerator in Linux kernel that enables a guest to use hardware-assisted virtualization technologies (AMD SVM , Intel VMX, and so on) as well as use confidential guest features like memory and virtual machine state encryption. It's part of the hypervisor and lives in the host kernel.

Because the guest CPU registers and VMCS are no longer accessible by the hypervisor, the confidential guest has to be re-initialized again by the hypervisor. Resetting the guest therefore means restoring the original boot state of the various CPU registers and re-initializing the confidential guest again from the beginning. The process involves encrypting guest private memory and performing the same architectural and non-architectural specific initialization steps all over again. This is the reason why we use the term “reset” in the context of a confidential guest. Because the reset is part of the reboot process, we may consider "reset" and "reboot" to mean the same thing.

Performing reset operations from the KVM (the host Linux kernel) would mean preserving the original boot state of the guest, which was likely described by an independent guest virtual machine (IGVM) bundle. This also includes the guest's private memory contents (for example, firmware). A reset or reboot of the guest with a new boot state (described by a different IGVM bundle) involves using a new mechanism (a new KVM VM IOCTL, perhaps) to push a reference to this bundle into KVM before reset. Duplicating the initial guest state in KVM and introducing a new KVM API is a complicated large change that introduces dependency with the Linux kernel. Kernels without support of the new KVM API won’t be able to boot into a new state. Additionally, it introduces duplication of the initial state as described by IGVM into KVM.

Another option is to perform the various reset specific operations from within QEMU, the userland hypervisor process, leaving KVM unchanged. KVM does not need to gain a new IOCTL or keep a copy of the initial guest state. The IGVM bundle is passed into QEMU as a command parameter. For a reboot, QEMU may use the same IGVM bundle or use a new one passed to it using guest memory or some other mechanism. The description of the initial guest boot state only lives in QEMU. This can then be used for reset. From KVM's perspective, the pre-reset guest and the post-reset guest can in fact be two different confidential virtual machines even if the userland QEMU process is the same one. The KVM context for the pre-reset virtual machine can be closed, thus tricking KVM into thinking that the pre-reset VM terminated.

For post-reset, a new KVM guest context can be opened by QEMU. Post-reset, from KVM’s perspective, this is a brand new guest. QEMU can perform all the architecture dependent and independent initialization steps all over again. This includes steps to initialize confidential guests. Everything can be driven from the userland QEMU process, just like when the guest was initially created. QEMU is aware of all the operations it performed while initializing the guest for the first time. QEMU needs to perform the same operations again.

Upgrade for new features

The second mechanism has been implemented in QEMU. Figure 1 describes the overall reset mechanism. FOSDEM 2026 presentation describes in more detail some of the additional steps required when a new KVM guest context is created post reset. The talk describes some of the testing strategies taken to exercise the changes. All changes are contained within the QEMU userland process, and there are no dependencies upon the kernel or KVM.

In order to get resettable/rebootable SEV-SNP and TDX VMs, you need only upgrade to QEMU version 11.0 and create confidential VMs. This new feature is then available on the very same Linux kernel/host with no additional dependencies. QEMU needs no additional command parameters. This feature is planned to be included in an upcoming version of Red Hat Enterprise Linux release in the near future.

Conclusion

Discussions continue in upstream communities on how to implement the mechanism of passing a different IGVM bundle to QEMU for use after a reset. We don't yet have full clarity on this. Also, IGVM support is currently only limited to SEV-SNP confidential guests, and not available for TDX guests in QEMU.

Resettable confidential guests bring a whole new set of challenges in the confidential computing space. Stateful confidential guests bring an entire new dimension of challenges as the state must be kept confidential between guest reboots. At Red Hat, we continue to seek solutions for these and other such questions.