[libvirt] [PATCH 4/4] qemu: caps: Format SEV platform data into qemuCaps cache

Erik Skultety eskultet at redhat.com
Thu Aug 16 07:02:55 UTC 2018


On Wed, Aug 15, 2018 at 06:23:28PM +0200, Peter Krempa wrote:
> On Wed, Aug 15, 2018 at 17:02:08 +0200, Erik Skultety wrote:
> > Since we're not saving the platform-specific data into a cache, we're
> > not going to populate the structure, which in turn will cause a crash
> > upon calling virNodeGetSEVInfo because of a NULL pointer dereference.
> > Ultimately, we should start caching this data along with host-specific
> > capabilities like NUMA and SELinux stuff into a separate cache, but for
> > the time being, this is a semi-proper fix for a potential crash.
> >
> > Backtrace (requires libvirtd restart to load qemu caps from cache):
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1612009
> > Signed-off-by: Erik Skultety <eskultet at redhat.com>
> > ---
> >  src/qemu/qemu_capabilities.c                      | 100 ++++++++++++++++++++++
> >  tests/domaincapsschemadata/qemu_2.12.0.x86_64.xml |   5 +-
> >  tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml |   6 ++
> >  3 files changed, 110 insertions(+), 1 deletion(-)
>
> ACK. I could not find any place where the data would be used by any code
> which would get it from the local copy from the @vm object, since that
> is not serialized in the domain status XML.

Thanks, note that this data is only supposed to serve the guest owner to
establish trust with the firmware in order to start a guest, therefore I
don't even expect this data to be used somewhere in the code ever. Yes, some of
the fields are re-used with launch-security data within the domain, but that is
a separate data structure not affected by the one this patch is about.

Erik





More information about the libvir-list mailing list