On 19.12.2023 14:15, Jan Beulich wrote: > 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?
Oh, no - what Linux logs are still the ACPI values (level: 0, edge: 1). What Xen logs are the IO-APIC values (level: 1, edge: 0). So all consistent here, and presumably indeed only a single call occurring. Jan
