On 18.12.2023 17:21, Sébastien Chaumat wrote: >>>>> On 05.12.2023 21:31, Sébastien Chaumat wrote: >>>>>>> [ 2.464598] amd_gpio AMDI0030:00: failed to enable wake-up interrupt >>>>>> >>>>>> Is it expected that IRQ7 goes from fasteoi (kernel 6.6.4 ) to >>>>>> ioapic-edge and IRQ9 to ioapic-level ? >>>>>> >>>>>> IR-IO-APIC 7-fasteoi pinctrl_amd >>>>>> IR-IO-APIC 9-fasteoi acpi >>>>>> >>>>>> to (xen 4.18.0) >>>>>> >>>>>> xen-pirq -ioapic-edge pinctrl_amd >>>>>> xen-pirq -ioapic-level acpi >>>>>> >>>>>> ? >>> > >>> This look similar to >>> https://yhbt.net/lore/all/20201006044941.fdjsp346kc5thyzy@Rk/t/ >>> >>> This issue seems that IRQ 7 (the GPIO controller) is natively fasteoi >>> (so level type) while in xen it is mapped to oapic-edge instead of >>> oapic-level >>> as the SSDT indicates : >>> >>> Device (GPIO) >>> >>> { >>> Name (_HID, "AMDI0030") // _HID: Hardware ID >>> Name (_CID, "AMDI0030") // _CID: Compatible ID >>> Name (_UID, Zero) // _UID: Unique ID >>> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings >>> { >>> Name (RBUF, ResourceTemplate () >>> { >>> Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, ) >>> { >>> 0x00000007, >>> } >>> Any idea why ? >> >> Information coming from AML is required to be handed down by Dom0 to Xen. >> May want checking that (a) Dom0 properly does so and (b) Xen doesn't screw >> up in consuming that data. See PHYSDEVOP_setup_gsi. I wonder if this is >> specific to it being IRQ7 which GPIO uses, as at the (master) PIC IRQ7 is >> also the spurious vector. You may want to retry with the tip of the 4.17 >> branch (soon to become 4.17.3) - while it doesn't look very likely to me >> that recent backports there were related, it may still be that they make >> a difference. >> > > testing with 4.17.3: > > Adding some printk in PHYSDEVOP_setup_gsi, I see (in xl dmesg) that > (XEN) PHYSDEVOP_setup_gsi setup_gsi : gsi: 7 triggering: 1 polarity: 1 > > but later on in dmesg I see : > [ 1.747958] xen: registering gsi 7 triggering 0 polarity 1
Linux has exactly one place where this message is logged from, and that's ahead of it calling PHYSDEVOP_setup_gsi. Since you said "later", can you confirm that actually you see two instances of the Xen message and two instances of the Linux one (each of them with respectively matching trigger and polarity values)? Or are we indeed observing what would look to be corruption of a hypercall argument? If there were two calls, it would be important to realize that Xen will respect only the first one. Jan
