Re: IOMMU faults after S3

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.04.2026 11:35, Marek Marczykowski-Górecki wrote:
> On Thu, Apr 02, 2026 at 10:39:41AM +0200, Jan Beulich wrote:
>> On 02.04.2026 10:08, Marek Marczykowski-Górecki wrote:
>>> The xl dmesg output (from MTL this time):
>>>
>>>     (XEN) [  123.477511] Entering ACPI S3 state.
>>>     (XEN) [18446743903.571842] _disable_pit_irq:2649: using_pit: 0, 
>>> cpu_has_apic: 1
>>>     (XEN) [18446743903.571856] _disable_pit_irq:2659: 
>>> cpuidle_using_deep_cstate: 1, boot_cpu_has(X86_FEATURE_XEN_ARAT): 0
> 
>> Hmm, but what you didn't log is whether __hpet_setup_msi_irq() actually
>> succeeded everywhere. (And if it did, also logging HPET_Tn_ROUTE() values
>> might be a good idea, if only to double check.)
> 
> Updated output:
> 
>     (XEN) [18446743899.720395] _disable_pit_irq:2649: using_pit: 0, 
> cpu_has_apic: 1
>     (XEN) [18446743899.720409] _disable_pit_irq:2659: 
> cpuidle_using_deep_cstate: 1, boot_cpu_has(X86_FEATURE_XEN_ARAT): 0
>     (XEN) [18446743899.720420] _disable_pit_irq:2662: init: 0
>     (XEN) [18446743899.720431] hpet_broadcast_resume:663: hpet_events: 
> ffff83046bc1f080
>     (XEN) [18446743899.720579] hpet_broadcast_resume:674: num_hpets_used: 8
>     (XEN) [18446743899.720587] hpet_broadcast_resume:692: cfg: 0x1
>     (XEN) [18446743899.720599] hpet_broadcast_resume:697: i:0, 
> hpet_events[i].msi.irq: 122, hpet_events[i].flags: 0
>     (XEN) [18446743899.720612] hpet_msi_write:283: iommu_intremap: 2 
> (iommu_intremap_off: 0), HPET_Tn_ROUTE(ch->idx): 0x110
>     (XEN) [18446743899.720638] hpet_msi_write:287: iommu_update_ire_from_msi 
> rc: 0

So it succeeds, and the low half of HPET_Tn_ROUTE also looks plausible. The high
half is, however, the address that the low half value is written to. It's hard
to imagine that it would be zero when the low half isn't, but it is about the
last thing I can think of which could explain observed behavior. (Yet then, all
of this is pretty meaningless; see below.)

> And the current debug diff attached.

Hmm, you log HPET_Tn_ROUTE _before_ our update. That's not very useful. You want
to move that part of logging to the bottom of hpet_msi_write(), or maybe to
where you also log the per-channel cfg value in hpet_broadcast_resume() (thus
making the logging overall less verbose).

Jan