All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Shavit <mshavit@google.com>
To: Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Joerg Roedel <joro@8bytes.org>
Cc: Michael Shavit <mshavit@google.com>,
	jean-philippe@linaro.org, nicolinc@nvidia.com, jgg@nvidia.com,
	baolu.lu@linux.intel.com, linux-arm-kernel@lists.infradead.org,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: [PATCH v1 0/5] Add PASID support to SMMUv3 unmanaged domains
Date: Thu, 11 May 2023 04:50:47 +0800	[thread overview]
Message-ID: <20230510205054.2667898-1-mshavit@google.com> (raw)

Hi all,

This patch series refactors the arm-smmu-v3 driver and implements the
set_dev_pasid functionality for DMA and UNMANAGED iommu domains. As part
of this effort, we also refactor the arm-smmu-v3 driver such that each
iommu domain represent a single address space. In particular, stage 1
domains hold a single ContextDescriptor instead of the entire STE entry.

The refactor is arguably valuable independently from the set_dev_pasid
feature since an iommu_domain is conceptually closer to a single address
space than an entire STE. In addition this unlocks some nice clean-up of
the arm SVA implementation which today piggybacks SVA domains on the
"primary" domain.

This patch series makes some changes to SVA and PCIe, but I haven't
tested those features. The cd table allocations could also be further
optimized for masters that don't support multiple context.  However, the
SMMUv3 Nested translation patch series has me worried about this
change. At a glance, it seems like this refactor conflicts with its
proposed uAPI. Is this refactor no longer an appropriate clean-up or
path forward for set_dev_pasid support? Or could a uAPI that only
exposes a single CD instead of the entire STE be an appropriate fit for
the nesting use cases?

Thanks,
Michael Shavit

Link: https://lore.kernel.org/all/CAKHBV24u9b-=cJCF=Kt=3B4hynOyNr6gmi0F6zpO6b1mHc0Z7g@mail.gmail.com
Link: https://lore.kernel.org/all/cover.1683688960.git.nicolinc@nvidia.com/

Michael Shavit (5):
  iommu/arm-smmu-v3: Move cdtable to arm_smmu_master
  iommu/arm-smmu-v3: Add has_stage1 field
  iommu/arm-smmu-v3: Simplify arm_smmu_enable_ats
  iommu/arm-smmu-v3: Keep track of attached ssids
  iommu/arm-smmu-v3: Implement set_dev_pasid

 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   |  46 +-
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 432 ++++++++++++------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  44 +-
 3 files changed, 344 insertions(+), 178 deletions(-)

-- 
2.40.1.521.gf1e218fcd8-goog


             reply	other threads:[~2023-05-10 20:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-10 20:50 Michael Shavit [this message]
2023-05-10 20:50 ` [PATCH v1 1/5] iommu/arm-smmu-v3: Move cdtable to arm_smmu_master Michael Shavit
2023-05-10 21:15   ` Jason Gunthorpe
2023-05-11 16:27     ` Michael Shavit
2023-05-10 20:50 ` [PATCH v1 2/5] iommu/arm-smmu-v3: Add has_stage1 field Michael Shavit
2023-05-10 20:50 ` [PATCH v1 3/5] iommu/arm-smmu-v3: Simplify arm_smmu_enable_ats Michael Shavit
2023-05-10 20:50 ` [PATCH v1 4/5] iommu/arm-smmu-v3: Keep track of attached ssids Michael Shavit
2023-05-10 21:24   ` Jason Gunthorpe
2023-05-11 15:26     ` Michael Shavit
2023-05-11 19:59       ` Jean-Philippe Brucker
2023-05-23  7:57         ` Michael Shavit
2023-05-23  7:57           ` Michael Shavit
2023-05-10 23:23   ` kernel test robot
2023-05-10 20:50 ` [PATCH v1 5/5] iommu/arm-smmu-v3: Implement set_dev_pasid Michael Shavit
2023-05-10 21:10 ` [PATCH v1 0/5] Add PASID support to SMMUv3 unmanaged domains Jason Gunthorpe
2023-05-11  3:52   ` Michael Shavit
2023-05-11  4:33     ` Jason Gunthorpe
2023-05-11 12:33       ` Robin Murphy
2023-05-11 15:54         ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230510205054.2667898-1-mshavit@google.com \
    --to=mshavit@google.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jean-philippe@linaro.org \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.