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. 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? Jan