On Tue, Dec 01, 2020 at 13:54:29 +0100, Michal Privoznik wrote: > In v6.0.0-rc1~439 (and friends) we tried to cache NUMA > capabilities because we assumed they are immutable. And to some > extent they are (NUMA hotplug is not a thing, is it). However, > our capabilities contain also some runtime info that can change, > e.g. hugepages pool allocation sizes or total amount of memory > per node (host side memory hotplug might change the value). > > When rebuilding virCaps (e.g. for 'virsh capabilities') we have > to dropped the cached info and rebuild it from scratch so that > the correct runtime info is reported. > > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1819058 > Fixes: 1a1d848694f6c2f1d98a371124928375bc3bb4a3 > Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> > --- > > After this, we are still caching CPU caps, but I'm not sure if that is a > problem. Perhaps if CPU was hotplugged/unplugged? I don't know. > > src/qemu/qemu_conf.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c > index d6615ca0dd..89a16349bf 100644 > --- a/src/qemu/qemu_conf.c > +++ b/src/qemu/qemu_conf.c > @@ -1380,6 +1380,12 @@ virCapsPtr virQEMUDriverCreateCapabilities(virQEMUDriverPtr driver) > "DOI \"%s\"", model, doi); > } > > + /* Forcibly recreate NUMA caps. They are not static > + * (e.g. size of hugepages pools can change). */ > + qemuDriverLock(driver); > + g_clear_pointer(&driver->hostnuma, virCapabilitiesHostNUMAUnref); > + qemuDriverUnlock(driver); The documentation for 'driver->hostnuma' says: /* Lazy initialized on first use, immutable thereafter. * Require lock to get the pointer & do optional initialization */ virCapsHostNUMAPtr hostnuma; This patch invalidates that. A very very quick glance at the code suggests that it's okay, since the accessor returns a reference, so the docs must be adjusted.
