Thread (149 messages) 149 messages, 7 authors, 2025-05-12

Re: [PATCH v2 17/19] iommu/arm-smmu-v3: Add arm_smmu_viommu_cache_invalidate

From: Nicolin Chen <hidden>
Date: 2024-09-11 20:53:45
Also in: linux-iommu, linux-kselftest, lkml

On Wed, Sep 11, 2024 at 08:13:01AM +0000, Tian, Kevin wrote:
quoted
quoted
quoted
Yes, many more patches, and don't try to do it now.. But we can copy
the vmid from the s2 and place it in the viommu struct during
allocation time.
does it assume that a viommu object cannot span multiple physical
IOMMUs so there is only one vmid per viommu?
I think so. One the reasons of introducing vIOMMU is to maintain
the shareability across physical IOMMUs at the s2 HWPT_PAGING.
I don't quite get it. e.g. for intel-iommu the S2 domain itself can
be shared across physical IOMMUs
SMMU does the same, but needs a VMID per pSMMU to tag that S2
domain:

vIOMMU0 (VMIDx of pSMMU0) -> shared S2
vIOMMU1 (VMIDy of pSMMU1) -> shared S2

Note: x and y might be different.
then what is the problem
preventing a vIOMMU object using that S2 to span multiple IOMMUs?
Jason previously suggested the way of implementing multi-vIOMMU
in a VMM to be one vIOMMU object representing a vIOMMU instance
(of a physical IOMMU) in the VM. So, it'd be only one VMID per
one vIOMMU object.

Sharing one vIOMMU object on the other hand needs the vIOMMU to
hold a list of VMIDs for all (or attached?) physical IOMMUs. This
would change what a vIOMMU object represents.
Probably there is a good reason e.g. for simplification or better
aligned with hw accel stuff. But it's not explained clearly so far.
I will try emphasizing that in the next version, likely in the
rst file that I am patching for HWPT_PAGING/NESTED at this point.

Thanks
Nicolin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help