src/conf/domain_capabilities.c | 2 + src/conf/domain_capabilities.h | 1 + src/conf/domain_conf.c | 7 +++ src/conf/domain_conf.h | 8 ++++ src/qemu/qemu_capabilities.c | 78 ++++++++++++++++++++++++---------- 5 files changed, 74 insertions(+), 22 deletions(-)
This introduces the new "model" field in sev elements so that clients can check whether SEV-ES, the 2nd generation of AMD SEV, is available in the taget hyprvisor. Takashi Kajinami (1): Expose available AMD SEV models in domain capabilities src/conf/domain_capabilities.c | 2 + src/conf/domain_capabilities.h | 1 + src/conf/domain_conf.c | 7 +++ src/conf/domain_conf.h | 8 ++++ src/qemu/qemu_capabilities.c | 78 ++++++++++++++++++++++++---------- 5 files changed, 74 insertions(+), 22 deletions(-) -- 2.43.0 _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org
On Mon, Feb 19, 2024 at 02:54:59PM +0900, Takashi Kajinami wrote: > This introduces the new "model" field in sev elements so that clients can > check whether SEV-ES, the 2nd generation of AMD SEV, is available in > the taget hyprvisor. Err, isn't this is already possible... https://libvirt.org/formatdomaincaps.html#sev-capabilities you'll see 'maxESGuests' give a non-zero number of SEV-ES is possible on a host. 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 :| _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org
My understanding is that these numbers retrieves number from CPU and do not actually represent whether SEV-ES is actually enabled in KVM. Because libvirt checks whether SEV is actually enabled in KVM, it makes it makes better sense to check the same for SEV-ES, IMO. Also, this "model" approach is likely needed for SEV-SNP, which shares the same ASID pool with SEV-ES by default. (though the implementation is still actively updated by AMD and is not yet merged into kernel or qemu now). On 2/19/24 18:58, Daniel P. Berrangé wrote: > On Mon, Feb 19, 2024 at 02:54:59PM +0900, Takashi Kajinami wrote: >> This introduces the new "model" field in sev elements so that clients can >> check whether SEV-ES, the 2nd generation of AMD SEV, is available in >> the taget hyprvisor. > > Err, isn't this is already possible... > > https://libvirt.org/formatdomaincaps.html#sev-capabilities > > you'll see 'maxESGuests' give a non-zero number of SEV-ES is possible > on a host. > > With regards, > Daniel _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org
Please ignore the current patch set. During further testing I noticed that further changes are needed to actually get the source flags set. I'll propose a fixed versions later. Sorry for the noise. On 2/19/24 14:54, Takashi Kajinami wrote: > This introduces the new "model" field in sev elements so that clients can > check whether SEV-ES, the 2nd generation of AMD SEV, is available in > the taget hyprvisor. > > Takashi Kajinami (1): > Expose available AMD SEV models in domain capabilities > > src/conf/domain_capabilities.c | 2 + > src/conf/domain_capabilities.h | 1 + > src/conf/domain_conf.c | 7 +++ > src/conf/domain_conf.h | 8 ++++ > src/qemu/qemu_capabilities.c | 78 ++++++++++++++++++++++++---------- > 5 files changed, 74 insertions(+), 22 deletions(-) > _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org
© 2016 - 2024 Red Hat, Inc.