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

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Feb 24, 2026 at 02:51:42PM +0000, Ankit Agrawal wrote:
> >> 
> >> Not arguing against this, but if there's a linux bug it is important
> >> to fix it as a 1st step. qemu work arounds for broken guests
> >> notwithstanding. then we can check how long the uapi has been around,
> >> how practical bugfix backport in linux is, and decide on whether
> >> a host side work around is worth it.
> >
> > Yeah, Ankit should provide more details to check for kernel bugs, but
> > I fear it is more userspace bugs in practice :\
> >
> > However, I think even if it is minor and easier to backport it still
> > doesn't matter. The CSPs all built their VM types for this HW with the
> > exepcted ACPI and this stuff is now very widely deployed. It makes no
> > sense for qemu to be incompatible with everything pre-existing...
> 
> I don't think this is a kernel bug. To give somewhat more details,
> we pass memory-less, cpu-less NUMA node to the VM such as
> the following through the command line.
> 
> qemu-system-aarch64 \
> ..
> -numa node,nodeid=2
> -object acpi-generic-initiator,id=gi0,pci-dev=dev0,node=2 \
> ..
> 
> The qemu code here only adds the numa node if the size > 0.
> https://github.com/qemu/qemu/blob/stable-10.2/hw/arm/virt-acpi-build.c#L718
> These nodes are thus discovered through the Generic Initiator
> Affinity SRAT structures that is build for the acpi-generic-initiator
> object such as the following.
> 
> 
> [1A0h 0416 001h]               Subtable Type : 05 [Generic Initiator Affinity]
> [1A1h 0417 001h]                      Length : 20
> 
> [1A2h 0418 001h]                   Reserved1 : 00
> [1A3h 0419 001h]          Device Handle Type : 01
> [1A4h 0420 004h]            Proximity Domain : 00000002
> [1A8h 0424 010h]               Device Handle : 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
> [1B8h 0440 004h]       Flags (decoded below) : 00000001
>                                      Enabled : 1
>                   Architectural Transactions : 0
> [1BCh 0444 004h]                   Reserved2 : 00000000
> 
> 
> Now the kernel parse it in the sequence of their occurrence. A jumbled up
> sequence thus results in a jumbled up assignment.
> 
> Thanks
> Ankit Agrawal

it can parse in any order it wants. but you are saying it exposes the
offset in the table as a proximity domain?