On 21.12.23 13:40, Jan Beulich wrote:
On 20.12.2023 17:34, Sébastien Chaumat wrote:Here are the patches I made to xen and linux kernel Plus dmesg (bare metal,xen) and "xl dmesg"So the problem looks to be that pci_xen_initial_domain() results in permanent setup of IRQ7, when there only "static" ACPI tables (in particular source overrides in MADT) are consulted. The necessary settings, however, are known only after _CRS for the device was evaluated (and possibly _PRS followed by invocation of _SRS). All of this happens before xen_register_gsi() is called. But that function's call to xen_register_pirq() is short-circuited by the very first if() in xen_register_pirq() when there was an earlier invocation. Hence the (wrong) "edge" binding remains in place, as was established by the earlier call here. Jürgen, there's an interesting comment in xen_bind_pirq_gsi_to_irq(), right before invoking irq_set_chip_and_handler_name(). Despite what the comment says (according to my reading), the fasteoi one is _not_ used in all cases. Assuming there's a reason for this, it's not clear to me whether updating the handler later on is a valid thing to do. __irq_set_handler() being even an exported symbol suggests that might be an option to use here. Then again merely updating the handler may not be sufficient, seeing there are also e.g. IRQD_TRIGGER_MASK and IRQD_LEVEL.
I understand the last paragraph of that comment to reason, that in case pirq_needs_eoi() return true even in case of an edge triggered interrupt, the outcome is still okay. I don't think updating the handler later is valid.
Sébastien, to prove the (still pretty weak) theory that the change in
handler is all that's needed to make things work in your case, could
you fiddle with pci_xen_initial_domain() to have it skip IRQ7? (That
of course won't be a proper solution, but ought to be okay for your
system.) The main weakness of the theory is that IRQ7 really isn't
very special in this regard - other PCI IRQs routed to the low 16
IO-APIC pins ought to have similar issues (from the log, on your
system this would be at least IRQ6 and IRQ10, except that they happen
to be edge/low, so fitting the ISA defaults); only IRQ16 and up would
work okay.
Furthermore it might be interesting to know whether ELCR would give us
any hint in this case. Sadly depending on where you look,
applicability of this pair of registers (I/O ports 0x4d0 and 0x4d1)
to other than EISA systems is claimed true or false. Could you perhaps
make Xen simply log the values read from those two ports, by e.g.
inserting
printk("ELCR: %02x, %02x\n", inb(0x4d0), inb(0x4d1));
in, say, setup_dump_irqs()?
Jürgen, looking at pci_xen_initial_domain(), what's the purpose of
the loop in the final if()? Can this ever do anything useful when
the earlier comment suggests nr_legacy_irqs() is zero anyway? Or is
the comment simply inaccurate in not covering the "no IO-APICs" case?
No, I think the final loop would only do something in case probe_8259A() is detecting a working PIC (which should not be the case IMHO). Could it be that there have been Xen versions emulating a PIC? The call of probe_8259A() is in no way depending on nr_ioapics. Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
