mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 10:11:27 +01:00
David Woodhouse
54102e428b
The emulated PIIX3 uses a nybble for the status of each PCI function, so the status for e.g. slot 0 functions 0 and 1 respectively can be read as (\_GPE.PH00 & 0x0F), and (\_GPE.PH00 >> 0x04). The AML that Xen gives to a guest gets the operand order for the odd- numbered functions the wrong way round, returning (0x04 >> \_GPE.PH00) instead. As far as I can tell, this was the wrong way round in Xen from the moment that PCI hotplug was first introduced in commit83d82e6f35: + ShiftRight (0x4, \_GPE.PH00, Local1) + Return (Local1) /* IN status as the _STA */ Or maybe there's bizarre AML operand ordering going on there, like Intel's wrong-way-round assembler, and it only broke later when it was changed to being generated? Either way, it's definitely wrong now, and instrumenting a Linux guest shows that it correctly sees _STA being 0x00 in function 0 of an empty slot, but then the loop in acpiphp_glue.c::get_slot_status() goes on to look at function 1 and sees that _STA evaluates to 0x04. Thus reporting an adapter is present in every slot in /sys/bus/pci/slots/* Quite why Linux wants to look for function 1 being physically present when function 0 isn't... I don't want to think about right now. Fixes:83d82e6f35("hvmloader: pass-through: multi-function PCI hot-plug") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Jan Beulich <jbeulich@suse.com> master commit:b190af7d3emaster date: 2023-03-20 17:12:34 +0100