Le jeu. 21 déc. 2023 à 14:29, Juergen Gross <jgr...@suse.com> a écrit :
> 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.
> >
>
Doing just that : IQR7 is now of type level
xen-pirq -ioapic-level pinctrl_amd
(but is ioapic-level there totally equivalent to the fasteoi of baremetal)
Still the touchpad does not work.
And we have now :
Dec 21 20:13:57 fedora kernel: i2c_hid_acpi i2c-PIXA3854:00: failed to
reset device: -61
Dec 21 20:14:17 fedora kernel: i2c_hid_acpi: probe of i2c-PIXA3854:00
failed with error -61
in addition to
Dec 21 20:13:57 fedora kernel: i2c_hid_acpi i2c-FRMW0004:00: failed to
reset device: -61
Dec 21 20:13:57 fedora kernel: i2c_hid_acpi i2c-FRMW0005:00: failed to
reset device: -61
Dec 21 20:14:17 fedora kernel: i2c_hid_acpi: probe of i2c-FRMW0004:00
failed with error -61
Dec 21 20:14:17 fedora kernel: i2c_hid_acpi: probe of i2c-FRMW0005:00
failed with error -61
I noticed that on baremetal :
53: 0 0 0 0 0 1268
0 0 0 0 0 0 0
0 0 0 amd_gpio 5 FRMW0005:00
54: 0 0 0 0 0 1
0 0 0 0 0 0 0
0 0 0 amd_gpio 84 FRMW0004:00
55: 0 0 0 0 0 1403
0 0 0 0 0 0 0
0 0 0 amd_gpio 8 PIXA3854:00
with xen with IRQ7 setup only once there's only (the touchpad is
PIXA3854:00)
176: 0 0 0 0 0 0
1 0 0 0 0 0 0
0 0 0 amd_gpio 8
Interestingly when IRQ7 is setup twice (normal xen)
176: 0 0 0 0 0 0
1 0 0 0 0 0 0
0 0 0 amd_gpio 8 PIXA3854:00
> 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()?
> >
>
did that but I don't know how to trigger the dump.
Sébastien
