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@xxxxxxxxxx> > > --- > > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
