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

From: Nicolin Chen <redacted>
Sent: Wednesday, September 11, 2024 3:21 PM

On Wed, Sep 11, 2024 at 06:25:16AM +0000, Tian, Kevin wrote:

quoted

quoted

From: Jason Gunthorpe <jgg@nvidia.com>
Sent: Friday, September 6, 2024 2:22 AM

On Thu, Sep 05, 2024 at 11:00:49AM -0700, Nicolin Chen wrote:

quoted

On Thu, Sep 05, 2024 at 01:20:39PM -0300, Jason Gunthorpe wrote:

quoted

On Tue, Aug 27, 2024 at 09:59:54AM -0700, Nicolin Chen wrote:

quoted

+static int arm_smmu_viommu_cache_invalidate(struct

iommufd_viommu *viommu,

quoted

quoted

quoted

+                                           struct iommu_user_data_array

*array)

quoted

quoted

quoted

+{
+       struct iommu_domain *domain =

iommufd_viommu_to_parent_domain(viommu);

quoted

quoted

quoted

+
+       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

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

that. Store the vmid, today copied from the nesting parent in the vmid
private struct. No need for iommufd_viommu_to_parent_domain(),

just

quoted

quoted

quoted

quoted

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.

I don't quite get it. e.g. for intel-iommu the S2 domain itself can
be shared across physical IOMMUs then what is the problem 
preventing a vIOMMU object using that S2 to span multiple IOMMUs?

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.