On Mon, 23 Feb 2026 10:44:11 +0100
Igor Mammedov <[email protected]> wrote:

> On Mon, 23 Feb 2026 07:49:51 +0000
> Ankit Agrawal <[email protected]> wrote:
> 
> > >> During creation of the VM's SRAT table, the generic initiator entries
> > >> are added. Currently the order in the entries are not controllable from
> > >> the qemu command. This is due to the fact that the code queries the
> > >> object tree which may not be in the order objects were inserted.
> > >>
> > >> As a fix the patch maintains a GPtrArray of generic initiator objects
> > >> that preserves their insertion order. Objects are automatically added
> > >> to the array when initialized and removed when finalized. When building
> > >> the SRAT table, objects are processed in the order they were first
> > >> inserted.    
> > >
> > > so question would be, why does it matter?
> > > Is ther a requirement in spec for SRAT entries being put in a particular 
> > > order?    
> > 
> > Hi Igor, reposting my response. I'll make this information as part of the 
> > next
> > version if and when I refresh.
> > 
> > VM's Linux kernel parses the generic initiator (GI) structures present in 
> > the SRAT
> > table sequentially in the order of their occurrence and assigns a numa node
> > id when a new proximity domain (that is part of the GI structure) is 
> > encountered.
> > A jumbled up entries in the VM's SRAT consequently results in the jumbled up
> > sequence on numa nodes v/s the ones intended to be assigned through the
> > qemu command line. This messes up the internode numa distances assignment
> > through the qemu command line as the VM's view of the corresponding nodes
> > is entirely different.  
> 
> Assuming that QEMU CLI is correctly defined, above looks very much like a 
> linux
> kernel bug.
> 
> Aka: if kernel is not mapping proximity ID to its internal node ids correctly
> and then links them with something else entirely, it's kernel in wrong
> and not ACPI tables QEMU provides.
> 
> IMHO it should be fixed on kernel side. (unless you find statement in spec
> that mandates the particular ordering in SRAT)
> 
Ankit, can you give an example complete with table dumps please.

I'm a little unsure on where things are getting scrambled.  Everything should be
keyed of PXM.   Sounds like we have a bug somewhere but ordering shouldn't be 
relevant.

Jonathan

> 


Reply via email to