>-----Original Message----- >From: Liu, Yi L <[email protected]> >Subject: Re: [PATCH v5 16/21] intel_iommu: Replay pasid bindings after >context cache invalidation > >On 2025/9/1 16:11, Duan, Zhenzhong wrote: >> >> >>> -----Original Message----- >>> From: Liu, Yi L <[email protected]> >>> Subject: Re: [PATCH v5 16/21] intel_iommu: Replay pasid bindings after >>> context cache invalidation >>> >>> On 2025/8/28 17:43, Eric Auger wrote: >>>> >>>> >>>> On 8/22/25 8:40 AM, Zhenzhong Duan wrote: >>>>> From: Yi Liu <[email protected]> >>>>> >>>>> This replays guest pasid bindings after context cache invalidation. >>>>> This is a behavior to ensure safety. Actually, programmer should issue >>>>> pasid cache invalidation with proper granularity after issuing a context >>>>> cache invalidation. >>>> So is this mandated? If the spec mandates specific invalidations and the >>>> guest does not comply with the expected invalidation sequence shall we >>>> do that behind the curtain? >>> >>> I think this is following the below decision. We can discuss if it's >>> really needed to replay the pasid bind. >>> >>> d4d607e40d (Peter Xu 2017-04-07 18:59:15 >+0800 >>> 2321) >>> /* >>> dd4d607e40d (Peter Xu 2017-04-07 18:59:15 >+0800 >>> 2322) * From VT-d spec 6.5.2.1, a global context entry invalidation >>> dd4d607e40d (Peter Xu 2017-04-07 18:59:15 >+0800 >>> 2323) * should be followed by a IOTLB global invalidation, so we >>> should >>> dd4d607e40d (Peter Xu 2017-04-07 18:59:15 >+0800 >>> 2324) * be safe even without this. Hoewever, let's replay the region >as >>> dd4d607e40d (Peter Xu 2017-04-07 18:59:15 >+0800 >>> 2325) * well to be safer, and go back here when we need finer tunes >>> for >>> dd4d607e40d (Peter Xu 2017-04-07 18:59:15 >+0800 >>> 2326) * VT-d emulation codes. >>> dd4d607e40d (Peter Xu 2017-04-07 18:59:15 >+0800 >>> 2327) */ >>> dd4d607e40d (Peter Xu 2017-04-07 18:59:15 >+0800 >>> 2328) vtd_iommu_replay_all(s); >> >> I have tested this series with this patch reverted, it works with guest linux >kernel. >> >> Personally, I am inclined to stop adding workaround for guest kenrel bug, >there will be more and more over time and it makes current code complex >unnecessarily. @Eric, @Liu, Yi L your thought? > >Let's go back to the original purpose of this. Peter has identified a >case in which a context modification is not followed by IOTLB >invalidation. [1] This is a valid behavior since the old domain is still >in use, no need to invalidate IOTLB. Hence the shadow page of the >changed device has not been updated. So the vIOMMU chose to enforce a >synchronization on the shadow page per context entry modification. Let's >see if similar requirement on PASID table.
Different devices can share one domain, but It's a rare case to see different devices sharing same PASID table except they are in same iommu group, but if they are in same iommu group, they should always use a common PASID table. I think no need to support such rare case? At least linux does not work this way. > >Let me ask one question: since PASID cache is also tagged with domain >ID, if the DID has not changed, maybe iommu driver will skip the PASID >cache flush? My understanding is no matter what's changed in PASID entry, there should be PASID cache invalidation, either domain scope, pasid scope or global invalidation. Thanks Zhenzhong > >[1] >https://lore.kernel.org/qemu-devel/[email protected] >/ > >Regards, >Yi Liu
