On Wed, Jun 29, 2022 at 07:37:01PM +0000, Dionna Glaze wrote:
> For SEV-SNP, an OS is "SEV-SNP capable" without supporting this UEFI
> v2.9 memory type. In order for OVMF to be able to avoid pre-validating
> potentially hundreds of gibibytes of data before booting, it needs to
> know if the guest OS can support its use of the new type of memory in
> the memory map.
This talks about something supported for SEV-SNP, but....
> static void
> sev_guest_class_init(ObjectClass *oc, void *data)
> {
> @@ -376,6 +401,14 @@ sev_guest_class_init(ObjectClass *oc, void *data)
> sev_guest_set_kernel_hashes);
> object_class_property_set_description(oc, "kernel-hashes",
> "add kernel hashes to guest firmware for measured Linux boot");
> + object_class_property_add_enum(oc, "accept-all-memory",
> + "MemoryAcceptance",
> + &memory_acceptance_lookup,
> + sev_guest_get_accept_all_memory, sev_guest_set_accept_all_memory);
> + object_class_property_set_description(
> + oc, "accept-all-memory",
> + "false: Accept all memory, true: Accept up to 4G and leave the rest unaccepted (UEFI"
> + " v2.9 memory type), default: default firmware behavior.");
> }
..this is adding a property to the 'sev-guest' object, which only
targets SEV/SEV-ES currently AFAIK.
The most recent patches I recall for SEV-SNP introduced a new
'sev-snp-guest' object instead of overloading the existing
'sev-guest' object:
https://lists.gnu.org/archive/html/qemu-devel/2021-08/msg04757.html
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
