Re: [REGRESSION] GPU passes into VM improperly after c376a3456d8b or a98db518dde2

[Baolu Lu]

On 5/26/26 03:57, 70sp wrote:
> > Have you tried this patch? It dumps the context and PASID table entries
> > after a domain is attached to the device. Hopefully, you can find some
> > clues by comparing the good and bad kernels.
> >
> > Thanks,
> > baolu
>
> https://lore.kernel.org/linux-iommu/uaUIyysjsnLHVLladjVXkuU63CTRoEzcw3BdlDX2cdkt8T82i0AX79VQAJo08uMKvpnn20xyK0Pu2PrtyMV3hmSgcwutWhV14fgjyTW3aiQ=@protonmail.com/
>
> I did, as I already wrote before. I looked through everything I could and was related, but I just haven't found anything. I don't know where else to look than I already did and documented before. If you have any idea where should I look for something, I will do so.

I’m having trouble accessing the links you provided.

As you noted, the first bad commit is either commit a98db518dde2
("iommu/vt-d: Enhance compatibility check for paging domain attach") or
commit c376a3456d8b ("iommu/vt-d: Remove domain_update_iommu_cap()").
These commits refactored the code to move hardware compatibility checks
into a helper, enforcing a policy where domain attachment fails if the
domain is incompatible with the hardware.

You confirmed that the domain attachment itself still succeeds both with
and without these commits. This suggests that the refactoring hasn't
altered the final result of the attachment process.

I am now investigating whether these changes affect the context or PASID
table entries. If the entries remain identical regardless of these
patches, it would indicate that these commits have no functional impact
on the hardware state. However, if there is a difference, we can then
analyze how that relates to the regression.

Thanks,
baolu