On 8/4/25 05:31, Andrea Bolognani wrote:
On Fri, Aug 01, 2025 at 11:39:45AM -0600, Jim Fehlig via Devel wrote:
With this addition, the correct firmware is detected, but it's not properly
provided to qemu
internal error: QEMU unexpectedly closed the monitor (vm='sles15sp7-snp'):
2025-08-01T17:11:20.589614Z qemu-system-x86_64: pflash with kvm requires KVM
readonly memory support
The pertinent command line pieces being
-blockdev
'{"driver":"file","filename":"/usr/share/qemu/ovmf-x86_64-sev.bin","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":
"unmap"}'
-blockdev
'{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}'
But for SNP, it needs to be provided as bios, e.g.
-bios /usr/share/qemu/ovmf-x86_64-sev.bin
Are we correctly identifying this firmware in the descriptor file? It's
advertised as a "flash" device, although I'm not sure if any of the other
"FirmwareDevice" options [1] are appropriate. Perhaps the
"FirmwareOSInterface" should be 'bios'?
Adding Michal and Daniel to the conversation so that they can provide
some insights. I have zero experience with SEV and no easy access to
the relevant hardware.
I don't follow qemu development close enough to know if pflash is now supported
with SNP guests. AFAIK, only '-bios' was supported when the initial SNP
enablement was merged.
Assuming that
* the need to use -bios for SEV-SNP is intended;
* pflash still needs to be used for SEV (-ES?);
* the edk2 build OVMF.amdsev.fd can be used for all variants;
then I think that we need to have the edk2 package ship two separate
descriptors pointing to the same file, one containing
{
"mapping": {
"device": "flash",
"mode": "stateless",
"executable": {
"filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd",
"format": "raw"
}
},
"features": [
"amd-sev",
"amd-sev-es"
]
}
for SEV(-ES) and one containing
{
"mapping": {
"device": "memory",
"filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd"
},
"features": [
"amd-sev-snp"
]
}
for SEV-SNP.
With those in place, libvirt will be able to know how it should
instruct QEMU to load the firmware. Hacking those changes into the
test suite seems to confirm this. You can make similar changes to
your local installation and test for yourself too.
I created a new descriptor file for SNP following your example and was able to
create/install an SNP-aware guest with
virt-install --boot uefi --launchSecurity sev-snp,policy=0x00030000 ...
Regards,
Jim
