From: Baolu Lu baolu.lu@linux.intel.com Sent: Wednesday, September 11, 2024 3:51 PM
On 2024/9/11 15:20, Nicolin Chen wrote:
On Wed, Sep 11, 2024 at 06:25:16AM +0000, Tian, Kevin wrote:
From: Jason Gunthorpejgg@nvidia.com Sent: Friday, September 6, 2024 2:22 AM
On Thu, Sep 05, 2024 at 11:00:49AM -0700, Nicolin Chen wrote:
On Thu, Sep 05, 2024 at 01:20:39PM -0300, Jason Gunthorpe wrote:
On Tue, Aug 27, 2024 at 09:59:54AM -0700, Nicolin Chen wrote:
> +static int arm_smmu_viommu_cache_invalidate(struct
iommufd_viommu *viommu,
> + struct iommu_user_data_array
*array)
> +{ > + struct iommu_domain *domain =
iommufd_viommu_to_parent_domain(viommu);
> + > + return __arm_smmu_cache_invalidate_user( > + to_smmu_domain(domain), viommu, array); I'd like to have the viommu struct directly hold the VMID. The nested parent should be sharable between multiple viommus, it doesn't make any sense that it would hold the vmid.
This is struggling because it is trying too hard to not have the driver allocate the viommu, and I think we should just go ahead and
do
that. Store the vmid, today copied from the nesting parent in the vmid private struct. No need for iommufd_viommu_to_parent_domain(),
just
rework the APIs to pass the vmid down not a domain.
OK. When I designed all this stuff, we still haven't made mind about sharing the s2 domain, i.e. moving the VMID, which might need a couple of more patches to achieve.
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.
My understanding of VMID is something like domain id in x86 arch's. Is my understanding correct?
yes
If a VMID for an S2 hwpt is valid on physical IOMMU A but has already been allocated for another purpose on physical IOMMU B, how can it be shared across both IOMMUs? Or the VMID is allocated globally?
I'm not sure that's a problem. The point is that each vIOMMU object will get a VMID from the SMMU which it's associated to (assume one vIOMMU cannot span multiple SMMU). Whether that VMID is globally allocated or per-SMMU is the policy in the SMMU driver.
It's the driver's responsibility to ensure not using a conflicting VMID when creating an vIOMMU instance.