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 10:42:43AM -0400, Jason Gunthorpe wrote:
> On Tue, Feb 24, 2026 at 09:01:30AM -0500, Michael S. Tsirkin wrote:
> > On Tue, Feb 24, 2026 at 09:51:06AM -0400, Jason Gunthorpe wrote:
> > > On Mon, Feb 23, 2026 at 11:13:02AM +0000, Jonathan Cameron wrote:
> > > 
> > > > 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.
> > > 
> > > I understood the issue is Linux assigns the uAPI visible NUMA node
> > > numbers based on the ordering. The proximity/etc internal to the
> > > kernel (I thought) was OK?
> > > 
> > > Then the problem is that uAPI has developed meaning based on what the
> > > bare metal HW does and now there are SW stacks that are expecting
> > > these platforms to have certain NUMA IDs in the Linux uAPI. Sure you
> > > can argue this is bad/etc/etc but the point of QEMU is to allow
> > > creating VMs that closely match real HW and in this instance real HW
> > > produces an ACPI table with a certain ordering and the SW is sensitive
> > > to this ordering.
> > > 
> > > Even if there is some Linux bug mis-parsing the ACPI, then that still
> > > should be addressed from a qemu perspective by providing the ACPI
> > > construction that doesn't trigger any bug so existing VM images will
> > > work under qemu.
> > > 
> > > Thus qemu needs a way to reflect the ordering on the command line to
> > > properly emulate this system and accomodate the existing VM software...
> > > 
> > > Jason
> > 
> > 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...
> 
> Jason

not having the data I can't judge, but this would be something to detail
in the commit log.  e.g. since which kernel version did it expose this,
etc etc.

regardless, asking that kernel fix is developed (if possible) and not
just a qemu workaround, is something i routinely do since otherwise it
is hard to find people willing to fix things properly.

-- 
MST