[PATCH] qemu: Recreate NUMA caps when creating connect capabilities

[Peter Krempa]

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 at redhat.com>
> ---
> 
> 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.