On 2025/9/1 16:11, Duan, Zhenzhong wrote:
-----Original Message-----
From: Liu, Yi L <yi.l....@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....@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.2b1f5...@t450s.home/
Regards,
Yi Liu
