On Fri, Jul 03, 2020 at 03:14:48PM +0200, Erik Skultety wrote: > Firstly, SEV is present only on AMD, so we can safely assume x86. > Secondly, the problem with looking up capabilities in the cache by arch > is that it's using virHashSearch with a callback to find the right > capabilities and get the binary name from it as well, but since the > cache is empty, it will return NULL and we won't get the corresponding > binary name out of the lookup either. Then, during the cache validation > we try to create a new cache entry for the emulator, but since we don't > have the binary name, nothing gets created. > Therefore, virQEMUCapsCacheLookupDefault is used to fix this issue, > because it doesn't rely on the capabilities cache to construct the > emulator binary name. > > https://bugzilla.redhat.com/show_bug.cgi?id=1852311 > > Signed-off-by: Erik Skultety <eskultet@xxxxxxxxxx> > --- > src/qemu/qemu_driver.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c > index a5b38b3d24..cd8d7ffb56 100644 > --- a/src/qemu/qemu_driver.c > +++ b/src/qemu/qemu_driver.c > @@ -22823,8 +22823,10 @@ qemuNodeGetSEVInfo(virConnectPtr conn, > if (virNodeGetSevInfoEnsureACL(conn) < 0) > return -1; > > - qemucaps = virQEMUCapsCacheLookupByArch(driver->qemuCapsCache, > - virArchFromHost()); > + qemucaps = virQEMUCapsCacheLookupDefault(driver->qemuCapsCache, > + NULL, NULL, NULL, NULL, > + NULL, NULL, NULL); > + Seems this removes the last usage of virQEMUCapsCacheLookupByArch so the whole method can go 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 :|
