Re: [PATCH v1 1/1] hw/acpi/pci.c: preserve generic initiator insertion order

[Igor Mammedov <imammedo@redhat.com>]

On Mon, 23 Feb 2026 07:49:51 +0000
Ankit Agrawal <ankita@nvidia.com> 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)