On Mon, Aug 28, 2023 at 02:10:42PM -0700, Derek Lee wrote: > When SEV is enabled in domcapabilities does that just mean any of SEV, > SEV-ES, SEV-SNP is possible on the hardware? No, <sev supported='yes'> only means that the CPU has 'sev' in the flags. On its own it doesn't say anything about the ES/SNP features. It might be possible to extract information whether these have been enabled on the HW via BIOS (or if they're enabled by default on new platforms) via the base64 encoded ID in the <cpu0Id> XML subelement, but that's just my guess. > > Similarly, does enabling SEV as a launchSecurity option in a domainXML mean > that whichever SEV is available will be enabled? And if the guest policy > has the ES flag set, it will not be created unless ES is enabled? Again, ES/SNP are just extra useful security features which sit on top of SEV (i.e. there's no such thing as "whichever" SEV), both serving a different purpose and both supposed to be transparent to the user, IOW if they're enabled on the HW they'll be used. Whether a VM is created if you explicitly request the ES flag via the guest policy on a non-ES enabled SEV CPU is totally dependent on AMD's FW behaviour as libvirt only passes through the values. Based on the SEV API spec, if you set ES in the guest policy SEV-ES must be enabled on the HW with no further information provided, so my assumption is that the FW will refuse to comply with such a request which in turn will result in QEMU returning a failure on creating such a VM. Again, totally based on my assumption it would be a design flaw of such a security feature if you requested the vCPU states to be included in the measurement with the ES policy flag and the FW would silently ignore the fact it's not enabled in HW and simply not include the data in the response. Regards, Erik
