>> >> 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
