[PATCH] libxl: Improve reporting of die_id in capabilities

Michal Prívozník mprivozn at redhat.com
Tue Sep 14 07:19:04 UTC 2021


On 9/14/21 12:01 AM, Jim Fehlig wrote:
> On Xen, libvirt runs in a VM (typically dom0) and does not have an accurate
> picture of numa and cpu topology of the underlying physical machine using
> the "usual" mechanisms. numa info and cpu toplogy are retrieved from libxl
> and used to populate the libvirt conterparts. Commit 7b79ee2f78b introduced
> support for reporting die_id in capabilities, but did not account for
> special handling of numa and cpu topology in libxl.
> 
> Currently, Xen does not report die_id in the libxl_cputopology structure.
> In the meantime, set die_id to 0, which was suggested by the Xen developers
> and is slightly better than random garbage such as
> 
> <cpu id='1' socket_id='0' die_id='-1073069552' core_id='0' siblings='0-1'/>
> 
> Signed-off-by: Jim Fehlig <jfehlig at suse.com>
> ---
>  src/libxl/libxl_capabilities.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/libxl/libxl_capabilities.c b/src/libxl/libxl_capabilities.c
> index b4bd1d7e62..4afed71436 100644
> --- a/src/libxl/libxl_capabilities.c
> +++ b/src/libxl/libxl_capabilities.c
> @@ -292,6 +292,8 @@ libxlCapsInitNuma(libxl_ctx *ctx, virCaps *caps)
>          cpus[node][nr_cpus_node[node]-1].id = i;
>          cpus[node][nr_cpus_node[node]-1].socket_id = cpu_topo[i].socket;
>          cpus[node][nr_cpus_node[node]-1].core_id = cpu_topo[i].core;
> +        /* Until Xen reports die_id, 0 is better than random garbage */
> +        cpus[node][nr_cpus_node[node]-1].die_id = 0;
>          /* Allocate the siblings maps. We will be filling them later */
>          cpus[node][nr_cpus_node[node]-1].siblings = virBitmapNew(nr_cpus);
>      }
> 

Oh right. It took me a while to realize where the garbage value might
come from. All I saw was g_new0() but then I came across VIR_REALLOC_N()
a few lines above this hunk. Therefore, the die_id can indeed be
uninitialized.

Reviewed-by: Michal Privoznik <mprivozn at redhat.com>

Michal




More information about the libvir-list mailing list