All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	iommu@lists.linux.dev, Jason Gunthorpe <jgg@nvidia.com>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Joerg Roedel <joro@8bytes.org>,
	dmaengine@vger.kernel.org, vkoul@kernel.org,
	Robin Murphy <robin.murphy@arm.com>,
	Will Deacon <will@kernel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Raj Ashok <ashok.raj@intel.com>,
	"Tian, Kevin" <kevin.tian@intel.com>, Yi Liu <yi.l.liu@intel.com>,
	"Yu, Fenghua" <fenghua.yu@intel.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Tony Luck <tony.luck@intel.com>,
	"Zanussi, Tom" <tom.zanussi@intel.com>,
	narayan.ranganathan@intel.com
Subject: Re: [PATCH v6 1/4] iommu: Generalize default PCIe requester ID PASID
Date: Tue, 23 May 2023 15:47:33 +0100	[thread overview]
Message-ID: <20230523144733.GA4137946@myrica> (raw)
In-Reply-To: <20230519203223.2777255-2-jacob.jun.pan@linux.intel.com>

Hi Jacob,

On Fri, May 19, 2023 at 01:32:20PM -0700, Jacob Pan wrote:
> PCIe Process address space ID (PASID) is used to tag DMA traffic, it
> provides finer grained isolation than requester ID (RID).
> 
> For each RID, 0 is as a special PASID for the legacy DMA (without
> PASID), thus RID_PASID. This is universal across all architectures,
> therefore warranted to be declared in the common header.
> Noting that VT-d could support none-zero RID_PASID, but currently not
> used.
> 
> By having a common RID_PASID, we can avoid conflicts between different
> use cases in the generic code. e.g. SVA and DMA API with PASIDs.
> 
> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> ---
> v6:
>    - let SMMU code use the common RID_PASID macro
> ---
>  .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   |  2 +-
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 10 ++++----
>  drivers/iommu/intel/iommu.c                   | 24 +++++++++----------
>  drivers/iommu/intel/pasid.c                   |  2 +-
>  drivers/iommu/intel/pasid.h                   |  1 -
>  include/linux/iommu.h                         |  1 +
>  6 files changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> index a5a63b1c947e..160b31e6239d 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> @@ -80,7 +80,7 @@ arm_smmu_share_asid(struct mm_struct *mm, u16 asid)
>  	 * be some overlap between use of both ASIDs, until we invalidate the
>  	 * TLB.
>  	 */
> -	arm_smmu_write_ctx_desc(smmu_domain, 0, cd);
> +	arm_smmu_write_ctx_desc(smmu_domain, IOMMU_DEF_RID_PASID, cd);

I agree with reserving 0 globally for non-PASID DMA, but could we call
this something more generic, like IOMMU_NO_PASID?  The term "RID_PASID" is
specific to VT-d and "RID" to PCI, so it looks confusing here (this driver
also supports non-PCI). "NO_PASID" would be clearer to someone just trying
to follow this driver code.

Thanks,
Jean


  parent reply	other threads:[~2023-05-23 14:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-19 20:32 [PATCH v6 0/4] Re-enable IDXD kernel workqueue under DMA API Jacob Pan
2023-05-19 20:32 ` [PATCH v6 1/4] iommu: Generalize default PCIe requester ID PASID Jacob Pan
2023-05-21  6:21   ` Baolu Lu
2023-05-23 14:47   ` Jean-Philippe Brucker [this message]
2023-05-23 15:26     ` Jacob Pan
2023-05-29 19:50   ` Jason Gunthorpe
2023-05-19 20:32 ` [PATCH v6 2/4] iommu: Move global PASID allocation from SVA to core Jacob Pan
2023-05-21  6:21   ` Baolu Lu
2023-05-22 17:32     ` Jacob Pan
2023-05-29 19:43   ` Jason Gunthorpe
2023-05-19 20:32 ` [PATCH v6 3/4] iommu/vt-d: Add set_dev_pasid callback for dma domain Jacob Pan
2023-05-29 19:48   ` Jason Gunthorpe
2023-05-30  2:19     ` Baolu Lu
2023-05-30 16:55       ` Jason Gunthorpe
2023-05-31  4:02         ` Baolu Lu
2023-05-19 20:32 ` [PATCH v6 4/4] dmaengine/idxd: Re-enable kernel workqueue under DMA API Jacob Pan
2023-05-21  6:29   ` Baolu Lu

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=20230523144733.GA4137946@myrica \
    --to=jean-philippe@linaro.org \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=fenghua.yu@intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=narayan.ranganathan@intel.com \
    --cc=robin.murphy@arm.com \
    --cc=tom.zanussi@intel.com \
    --cc=tony.luck@intel.com \
    --cc=vkoul@kernel.org \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.com \
    /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.