Re: [PATCH v5 16/21] intel_iommu: Replay pasid bindings after context cache invalidation

[Yi Liu <yi.l.liu@intel.com>]

On 2025/9/1 16:11, Duan, Zhenzhong wrote:
> 
> 
>> -----Original Message-----
>> From: Liu, Yi L <yi.l.liu@intel.com>
>> 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 <yi.l.liu@intel.com>
>>>>
>>>> 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.

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?

[1] https://lore.kernel.org/qemu-devel/20170117084604.2b1f5e50@t450s.home/

Regards,
Yi Liu