Overview | Upstream Support | Prepare Host | Build & Install | Launch Guest | Additional Resources | FAQ
This repo will build host/guest kernel, QEMU, and OVMF packages that are known to work in conjunction with the latest development trees for SEV Feature host/hypervisor support. The build scripts will utilize the latest published development tree for the SNP host kernel, which will generally correspond to the latest patchset posted upstream along with fixes/changes on top resulting from continued development/testing and upstream review. It will also utilize the latest published development tree for QEMU.
Note that while base SEV 3.0 (SNP) support is upstream (see Upstream Version Reference), additional features are still being actively developed and upstreamed. Branches of this repository provide early snapshots of those features. Please report any issues via the issue tracker.
AMD Secure Encrypted Virtualization (SEV) is a set of extensions to the AMD-V architecture for running encrypted virtual machines (VMs) under KVM. Each AMD EPYC processor family has introduced SEV improvements, sometimes with a milestone feature.
| SEV Version | EPYC Platform | Description |
|---|---|---|
| SEV 1.0 | EPYC 7001 | Encrypts guest memory pages so only the guest has access to unencrypted data. Each VM uses a unique encryption key. |
| SEV 2.0 (ES - Encrypted State) | EPYC 7002 | Encrypts guest register state during world switches, preventing the hypervisor from directly accessing or modifying registers. Guests are notified before certain world switches via a new exception, allowing selective information sharing. |
| SEV 3.0 (SNP - Secure Nested Paging) | EPYC 7003 | Protects guest memory integrity via the Reverse Map Table (RMP), a system-managed structure that tracks ownership and state of each physical page. Prevents hypervisor-based memory remapping attacks by enforcing single-guest page assignment and validating all memory state transitions. |
| SEV 3.1 | EPYC 9004/8004 | SNP enhancements - increases ASID key count to 1006 (vs. 509 on EPYC 7003). |
Note: "Legacy SEV" refers to the first generation. This README uses feature acronyms (SEV-ES, SEV-SNP) when referring to specific software interfaces.
This repository provides scripts to build host/guest kernels, QEMU, and OVMF from AMD's development branches for SEV 3.0+ (SNP). This README covers host setup, upstream version requirements, and then walks through launching SEV guests.
The main branch tracks the
snp-host-latest kernel and
snp-latest QEMU trees, which
carry patches under active upstream review. Current development features include:
| Feature | Component | Description |
|---|---|---|
| guest_memfd hugepage support | Kernel (46cf7f3, c0e0812) + QEMU (afe54d0) | Hugepage-backed private guest memory for improved performance. |
| PCI passthrough | QEMU (565ac02, e7af839) | QEMU support for using PCI passthrough with SEV-SNP VMs. |
| CipherTextHiding | Kernel (799613d, d747c33, e115032, 65e2f4f) | Prevents ciphertext side-channel attacks on SNP guests. |
| SNP policy bit publishing | Kernel (c8e9926, 088f53d, 5bf85ca, 4ccd326) | Exposes supported SEV-SNP policy bits to userspace via the CCP/PSP driver. |
| SNP_FEATURE_INFO command | Kernel (49dbeaf, b348455, c268cdd) | New firmware command to query SNP feature support. |
As these features land upstream, they will be removed from the development branches and this list.
Modern distributions ship all the components needed to run SEV 3.0+ (SNP) guests without building anything from source.
For a list of OS distributions that have been tested and certified for SEV feature support across EPYC platforms, see sev-certify.
| Minimum Version | SEV 1.0 | SEV 2.0 (ES) | SEV 3.0 (SNP) |
|---|---|---|---|
| Kernel (host) | 4.16 | 5.11 | 6.11 |
| Kernel (guest) | 4.16 | 5.11 | 5.19 (6.11 recommended; full attestation and guest_memfd) |
| QEMU | 2.12 | 6.0 | 9.1 |
| OVMF | 75b7aa9528bd | edk2-stable202102 | edk2-stable202405 |
| libvirt | 4.5 | 4.5 | 10.5.0 |
| SEV FW | — | — | 1.51 (0x33) |
| PSP BootLoader | — | — | 00.13.00.70 (AGESA PI 1.0.0.9+) |
| Platform | EPYC 7001+ | EPYC 7002+ | EPYC 7003+ |
SEV 3.1 (EPYC 9004/8004) uses the same software stack as SEV 3.0 with additional hardware capabilities.
These requirements apply regardless of whether you use distribution
packages or build from source. Optionally install
snphost and run snphost ok
for a comprehensive host readiness check of all requirements below
(CPU/BIOS/FW).
SEV 3.0 (SNP) requires an AMD EPYC processor with Zen 3 or newer microarchitecture. See the SEV Features table for platform requirements by SEV version.
Verify that the following BIOS settings are enabled. The setting may vary based on the vendor BIOS. The menu options below are from an AMD BIOS.
Advanced → AMD CBS → CPU Common Options
SMEE → Enable
SEV Control → Enable
SEV-ES ASID Space Limit → 99
SNP Memory (RMP Table) Coverage → Enabled
Advanced → NBIO Common Options → IOMMU/Security
SEV-SNP Support → Enable
Minimum firmware versions are listed in the
Upstream Version Reference table above.
The latest firmware is available at developer.amd.com/sev and via
the linux-firmware package.
To manually update firmware (example for EPYC 7003 Series):
# wget https://download.amd.com/developer/eula/sev/amd_sev_fam19h_model0xh_1.54.01.zip
# unzip amd_sev_fam19h_model0xh_1.54.01.zip
# sudo mkdir -p /lib/firmware/amd
# sudo cp amd_sev_fam19h_model0xh_1.54.01.sbin /lib/firmware/amd/amd_sev_fam19h_model0xh.sbin
Then either reboot the host, or reload the ccp driver to complete the firmware upgrade process:
sudo rmmod kvm_amd
sudo rmmod ccp
sudo modprobe ccp
sudo modprobe kvm_amd
Run the following commands to verify that SNP is enabled in the host.
# dmesg | grep -e SEV-SNP -e RMP
SEV-SNP: Segmented RMP base table physical range [0x000000009ba00000 - 0x000000009ba05000]
SEV-SNP: Reserving start/end of RMP table on a 2MB boundary [0x0000000055a00000]
SEV-SNP: Reserving start/end of RMP table on a 2MB boundary [0x0000000075a00000]
SEV-SNP: Segmented RMP using 128GB segments
SEV-SNP: RMP segment 0 physical address [0x8800000 - 0x10ffffff] covering [0x0 - 0x87fffffff]
SEV-SNP: RMP segment 8 physical address [0x55b00000 - 0x75afffff] covering [0x10000000000 - 0x11fffffffff]
SEV-SNP: RMP segment 9 physical address [0x35a00000 - 0x559fffff] covering [0x12000000000 - 0x13fffffffff]
ccp 0000:a9:00.5: SEV-SNP API:1.58 build:5
kvm_amd: SEV-SNP enabled (ASIDs 1 - 98)
# cat /sys/module/kvm_amd/parameters/sev
Y
# cat /sys/module/kvm_amd/parameters/sev_es
Y
# cat /sys/module/kvm_amd/parameters/sev_snp
Y
Notes:
- EPYC 7003 Series systems require the minimum PSP BootLoader version listed in the Upstream Version Reference table. Attempting to update firmware with an older BootLoader will fail with
SEV: failed to INIT error 0x1, rc -5. Update the system BIOS if you see this error. - For EPYC 9004 Series systems, SEV firmware updates are delivered through system BIOS updates.
You may skip this step if you do not require development patches not yet available upstream.
The main branch builds development patches beyond base SEV 3.0 (SNP) that are not yet available upstream (see Development Features). It builds host/guest kernels, QEMU, and OVMF from AMD development trees.
The following command builds the host and guest Linux kernel, QEMU, and OVMF used for launching an SEV-SNP guest.
Target repositories and branches are determined by stable-commits.
# git clone https://github.com/AMDESE/AMDSEV.git
# ./build.sh --package
# sudo cp kvm.conf /etc/modprobe.d/
On successful build, the binaries will be available in snp-release-<DATE>.
NOTE: edk2 build issues are often caused by stale submodule state.
Delete the ovmf/ directory and rebuild to force a fresh clone.
Run the following command to install the Linux kernel on the host machine.
# cd snp-release-<date>
# ./install.sh
Reboot the machine and choose SNP Host kernel from the grub menu.
Note: SNP requires OVMF be used as the guest BIOS in order to boot. This implies that the guest must have been initially installed using OVMF so that a UEFI partition is present.
If you do not already have an installed guest, you can use the launch-qemu.sh script to create it (be sure to append "console=ttyS0,115200n8" to the installation kernel command line in order to perform the installation via the serial console):
# ./launch-qemu.sh -hda <your_qcow2_file> -cdrom <your_distro_installation_iso_file>
Boot up a guest (tested with Ubuntu 22.04 and 24.04, but any standard *.deb or *.rpm-based distro should work) and install the guest kernel packages built in the previous step. The guest kernel packages are available in 'snp-release-/linux/guest' directory.
To launch the SNP guest use the launch-qemu.sh script provided in this repository
# ./launch-qemu.sh -hda <your_qcow2_file> -sev-snp
To launch SNP disabled guest, simply remove the "-sev-snp" from the above command line.
Once the guest is booted, run the following command inside the guest VM to verify that SNP is enabled:
$ dmesg | grep -i snp
AMD Memory Encryption Features active: SEV SEV-ES SEV-SNP
- AMD SEV Developer Portal
- AMD SME/SEV White Paper (PDF)
- SEV Secure Key Management API Specification (PDF)
- AMD64 Architecture Programmer's Manual, Volume 2 -- Section 15.34: SEV (PDF)
- KVM Forum Presentation Slides -- AMD Virtualization Memory Encryption (PDF)
- KVM Forum Presentation Video -- AMD Memory Encryption (YouTube)
- Linux Kernel Documentation -- KVM AMD Memory Encryption (RST)
- Linux Kernel Documentation -- x86 AMD Memory Encryption (TXT)
- Libvirt Domain XML -- LaunchSecurity SEV
- Libvirt Knowledge Base -- Launch Security with SEV
- Libvirt Domain Capabilities -- SEV
- QEMU Documentation -- AMD Memory Encryption
- guest_memfd (a.k.a. "gmem") -- Unmapped Private Memory (lore.kernel.org)
- AMD SEV Enablement Guide (PDF)
-
How do I know if hypervisor supports SEV feature ?
a) When using libvirt >= 4.15 run the following command
# virsh domcapabilitiesIf hypervisor supports SEV feature then sev tag will be present.
See Libvirt DomainCapabilities feature for additional information.
b) Use qemu QMP 'query-sev-capabilities' command to check the SEV support. If SEV is supported then command will return the full SEV capabilities (which includes host PDH, cert-chain, cbitpos and reduced-phys-bits).
See QMP doc for details on how to interact with QMP shell.
-
How do I know if SEV is enabled in the guest ?
a) Check the kernel log buffer for the following message
# dmesg | grep -i sev AMD Secure Encrypted Virtualization (SEV) activeb) MSR 0xc0010131 (MSR_AMD64_SEV) can be used to determine if SEV is active
# rdmsr -a 0xc0010131Bit[0]: 0 = SEV is not active 1 = SEV is active
-
Can I use virt-manager to launch SEV guest?
virt-manager uses libvirt to manage VMs, SEV support has been added in libvirt but virt-manager does use the newly introduced LaunchSecurity tags yet hence we will not able to launch SEV guest through the virt-manager.
If your system is using libvirt >= 4.15 then you can manually edit the xml file to use LaunchSecurity to enable the SEV support in the guest.
- How to increase SWIOTLB limit ?
When SEV is enabled, all the DMA operations inside the guest are performed on the shared memory. Linux kernel uses SWIOTLB bounce buffer for DMA operations inside SEV guest. A guest panic will occur if kernel runs out of the SWIOTLB pool. Linux kernel default to 64MB SWIOTLB pool. It is recommended to increase the swiotlb pool size to 512MB. The swiotlb pool size can be increased in guest by appending the following in the grub.cfg file
Append the following in /etc/defaults/grub
GRUB_CMDLINE_LINUX_DEFAULT=".... swiotlb=262144"
And regenerate the grub.cfg.
- SWIOTLB allocation failure causing kernel panic
SWIOTLB size, when not specifically specified, is automatically calculated based on the amount of guest memory, up to 1GB maximum. However, the guest may not have enough contiguous memory below 4GB to satisfy the SWIOTLB allocation requirement, in which case the kernel will panic:
[ 0.004318] software IO TLB: SWIOTLB bounce buffer size adjusted to 965MB ... [ 1.015953] Kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
In this situation, please specify the SWIOTLB size, as shown in How to increase SWIOTLB limit, to a value that allows the guest to boot.
- virtio-blk device runs out-of-dma-buffer error
To support the multiqueue mode, virtio-blk drivers inside the guest allocates large number of DMA buffer. SEV guest uses SWIOTLB for the DMA buffer allocation or mapping hence kernel runs of the SWIOTLB pool quickly and triggers the out-of-memory error. In those cases consider increasing the SWIOTLB pool size or use virtio-scsi device.
- SEV_INIT fails with error 0x13
The error 0x13 is a defined as HWERROR_PLATFORM in the SEV specification. The error indicates that memory encryption support is not enabled in the host BIOS. Look for the SMEE setting in your BIOS menu and explicitly enable it. You can verify that SMEE is enabled on your machine by running the below command
$ sudo modprobe msr
$ sudo rdmsr 0xc0010010
3f40000
Verify that BIT23 is memory encryption (aka SMEE) is set.