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(a)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