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@xxxxxxxx> > --- > 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@xxxxxxxxxx> Michal
