Re: IOMMU faults after S3

[Jan Beulich <jbeulich@xxxxxxxx>]

On 01.04.2026 09:20, Andrew Cooper wrote:
> On 01/04/2026 9:14 am, Jan Beulich wrote:
>> On 27.03.2026 11:19, Marek Marczykowski-Górecki wrote:
>>> I noticed that on some systems, there are a lot of IOMMU faults after
>>> S3. I can see it also on a laptop with MTL, but it affects also the ADL
>>> gitlab runner:
>>>
>>>     https://gitlab.com/xen-project/hardware/xen/-/jobs/13661033722
>>>     (XEN) [   37.201160] [VT-D]DMAR:[DMA Write] Request device 
>>> [0000:00:1e.6] fault addr 0
>>>     (XEN) [   37.201164] [VT-D]DMAR: reason 02 - Present bit in context 
>>> entry is clear
>>>     (XEN) [   37.202332] [VT-D]DMAR:[DMA Write] Request device 
>>> [0000:00:1e.6] fault addr 0
>>>     (XEN) [   37.202339] [VT-D]DMAR: reason 02 - Present bit in context 
>>> entry is clear
>>>
>>> Interestingly, the 0000:00:1e.6 device is not even listed by lspci.
>>>
>>> The issue is present only on staging, not staging-4.21.
>>>
>>> Bisect says:
>>>
>>> 5ec93b2f19ff8873fca65d38c1164b0a56d3898b is the first bad commit
>>> commit 5ec93b2f19ff8873fca65d38c1164b0a56d3898b
>>> Author: Jan Beulich <jbeulich@xxxxxxxx>
>>> Date:   Thu Jan 22 14:13:35 2026 +0100
>>>
>>>     x86/HPET: drop .set_affinity hook
>> Looking into this, I find several things I can't quite understand (yet).
>> First there is
>>
>> (XEN) [000000456c0fe39f] Disabling HPET for being unreliable
>>
>> which looks to only affect clocksource selection, but not use as
>> broadcast source for CPU-idle management. (This may be an independent
>> issue.)
>>
>> Then there is
>>
>> (XEN) [    2.760248] HPET: 8 timers usable for broadcast (8 total)
>>
>> which should only occur on ARAT-incapable systems. That should only be
>> older hardware.
> 
> I'm not sure that's a reasonable assertion to draw.  The number of HPET
> channels is down to the HPET alone, not anything to do with the CPU
> capabilities.

My statement was about the mere presence of that message, not the number
of channels that are reported.

>>  (On my much older Skylake I don't see this line, for
>> example.) What does CPUID leaf 6 have on this system? Sadly xen-cpuid
>> is purely featureset based, and hence doesn't expose info about that
>> leaf.
> 
> xen-cpuid -p
> 
> That will get you leaf 6, but there's no human-readable decode of it.

Raw numbers is good enough here. How did I miss that option when looking
at --help output? Oh, simply because it isn't shown there.

Marek, that'll be better than bare metal kernel data, as it gives us both
raw and host policies.

Jan