On 17.03.2023 11:32, David Woodhouse wrote: > From: David Woodhouse <[email protected]> > > 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 commit 83d82e6f35a8: > > + 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. > > Signed-off-by: David Woodhouse <[email protected]> > Fixes: 83d82e6f35a8 ("hvmloader: pass-through: multi-function PCI hot-plug")
Reviewed-by: Jan Beulich <[email protected]>
