All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: iommu@lists.linux-foundation.org,
	LKML <linux-kernel@vger.kernel.org>,
	dmaengine@vger.kernel.org, Joerg Roedel <joro@8bytes.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Jean-Philippe Brucker <jean-philippe@linaro.com>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	vkoul@kernel.org, robin.murphy@arm.com, will@kernel.org,
	Yi Liu <yi.l.liu@intel.com>, Dave Jiang <dave.jiang@intel.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	Raj Ashok <ashok.raj@intel.com>,
	Eric Auger <eric.auger@redhat.com>
Subject: Re: [PATCH v3 1/4] iommu/vt-d: Implement domain ops for attach_dev_pasid
Date: Wed, 11 May 2022 08:54:27 -0300	[thread overview]
Message-ID: <20220511115427.GU49344@nvidia.com> (raw)
In-Reply-To: <20220510172309.3c4e7512@jacob-builder>

On Tue, May 10, 2022 at 05:23:09PM -0700, Jacob Pan wrote:

> > > diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
> > > index 5af24befc9f1..55845a8c4f4d 100644
> > > +++ b/include/linux/intel-iommu.h
> > > @@ -627,6 +627,7 @@ struct device_domain_info {
> > >  	struct intel_iommu *iommu; /* IOMMU used by this device */
> > >  	struct dmar_domain *domain; /* pointer to domain */
> > >  	struct pasid_table *pasid_table; /* pasid table */
> > > +	ioasid_t pasid; /* DMA request with PASID */  
> > 
> > And this seems wrong - the DMA API is not the only user of
> > attach_dev_pasid, so there should not be any global pasid for the
> > device.
> > 
> True but the attach_dev_pasid() op is domain type specific. i.e. DMA API
> has its own attach_dev_pasid which is different than sva domain
> attach_dev_pasid().

Huh? The intel driver shares the same ops between UNMANAGED and DMA -
and in general I do not think we should be putting special knowledge
about the DMA domains in the drivers. Drivers should continue to treat
them identically to UNMANAGED.

> device_domain_info is only used by DMA API.

Huh?
 
> > I suspect this should be a counter of # of pasid domains attached so
> > that the special flush logic triggers
> > 
> This field is only used for devTLB, so it is per domain-device. struct
> device_domain_info is allocated per device-domain as well. Sorry, I might
> have totally missed your point.

You can't store a single pasid in the driver like this, since the only
thing it does is trigger the flush logic just count how many pasids
are used by the device-domain and trigger pasid flush if any pasids
are attached

> > And rely on the core code to worry about assigning only one domain per
> > pasid - this should really be a 'set' function.
>
> Yes, in this set the core code (in dma-iommu.c) only assign one PASID per
> DMA domain type.
> 
> Are you suggesting the dma-iommu API should be called
> iommu_set_dma_pasid instead of iommu_attach_dma_pasid?

No that API is Ok - the driver ops API should be 'set' not attach/detach

Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe via iommu <iommu@lists.linux-foundation.org>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: vkoul@kernel.org, "Tian, Kevin" <kevin.tian@intel.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Raj Ashok <ashok.raj@intel.com>,
	will@kernel.org, David Woodhouse <dwmw2@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	iommu@lists.linux-foundation.org, dmaengine@vger.kernel.org,
	robin.murphy@arm.com,
	Jean-Philippe Brucker <jean-philippe@linaro.com>
Subject: Re: [PATCH v3 1/4] iommu/vt-d: Implement domain ops for attach_dev_pasid
Date: Wed, 11 May 2022 08:54:27 -0300	[thread overview]
Message-ID: <20220511115427.GU49344@nvidia.com> (raw)
In-Reply-To: <20220510172309.3c4e7512@jacob-builder>

On Tue, May 10, 2022 at 05:23:09PM -0700, Jacob Pan wrote:

> > > diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
> > > index 5af24befc9f1..55845a8c4f4d 100644
> > > +++ b/include/linux/intel-iommu.h
> > > @@ -627,6 +627,7 @@ struct device_domain_info {
> > >  	struct intel_iommu *iommu; /* IOMMU used by this device */
> > >  	struct dmar_domain *domain; /* pointer to domain */
> > >  	struct pasid_table *pasid_table; /* pasid table */
> > > +	ioasid_t pasid; /* DMA request with PASID */  
> > 
> > And this seems wrong - the DMA API is not the only user of
> > attach_dev_pasid, so there should not be any global pasid for the
> > device.
> > 
> True but the attach_dev_pasid() op is domain type specific. i.e. DMA API
> has its own attach_dev_pasid which is different than sva domain
> attach_dev_pasid().

Huh? The intel driver shares the same ops between UNMANAGED and DMA -
and in general I do not think we should be putting special knowledge
about the DMA domains in the drivers. Drivers should continue to treat
them identically to UNMANAGED.

> device_domain_info is only used by DMA API.

Huh?
 
> > I suspect this should be a counter of # of pasid domains attached so
> > that the special flush logic triggers
> > 
> This field is only used for devTLB, so it is per domain-device. struct
> device_domain_info is allocated per device-domain as well. Sorry, I might
> have totally missed your point.

You can't store a single pasid in the driver like this, since the only
thing it does is trigger the flush logic just count how many pasids
are used by the device-domain and trigger pasid flush if any pasids
are attached

> > And rely on the core code to worry about assigning only one domain per
> > pasid - this should really be a 'set' function.
>
> Yes, in this set the core code (in dma-iommu.c) only assign one PASID per
> DMA domain type.
> 
> Are you suggesting the dma-iommu API should be called
> iommu_set_dma_pasid instead of iommu_attach_dma_pasid?

No that API is Ok - the driver ops API should be 'set' not attach/detach

Jason
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2022-05-11 11:54 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-10 21:07 [PATCH v3 0/4] Enable PASID for DMA API users Jacob Pan
2022-05-10 21:07 ` Jacob Pan
2022-05-10 21:07 ` [PATCH v3 1/4] iommu/vt-d: Implement domain ops for attach_dev_pasid Jacob Pan
2022-05-10 21:07   ` Jacob Pan
2022-05-10 23:21   ` Jason Gunthorpe
2022-05-10 23:21     ` Jason Gunthorpe via iommu
2022-05-11  0:23     ` Jacob Pan
2022-05-11  0:23       ` Jacob Pan
2022-05-11 11:54       ` Jason Gunthorpe [this message]
2022-05-11 11:54         ` Jason Gunthorpe via iommu
2022-05-11 15:35         ` Jacob Pan
2022-05-11 15:35           ` Jacob Pan
2022-05-11 16:12           ` Jason Gunthorpe
2022-05-11 16:12             ` Jason Gunthorpe via iommu
2022-05-11 17:02             ` Jacob Pan
2022-05-11 17:02               ` Jacob Pan
2022-05-11 17:00               ` Jason Gunthorpe
2022-05-11 17:00                 ` Jason Gunthorpe via iommu
2022-05-11 17:25                 ` Jacob Pan
2022-05-11 17:25                   ` Jacob Pan
2022-05-11 18:29                   ` Jason Gunthorpe
2022-05-11 18:29                     ` Jason Gunthorpe via iommu
2022-05-18 18:42                     ` Jacob Pan
2022-05-18 18:42                       ` Jacob Pan
2022-05-18 18:52                       ` Jason Gunthorpe
2022-05-18 18:52                         ` Jason Gunthorpe via iommu
2022-05-19 21:05                         ` Jacob Pan
2022-05-19 21:05                           ` Jacob Pan
2022-05-12  1:16                   ` Baolu Lu
2022-05-12  1:16                     ` Baolu Lu
2022-05-12  6:22                 ` Baolu Lu
2022-05-12  6:22                   ` Baolu Lu
2022-05-12 11:52                   ` Jason Gunthorpe
2022-05-12 11:52                     ` Jason Gunthorpe via iommu
2022-05-10 21:07 ` [PATCH v3 2/4] iommu: Add PASID support for DMA mapping API users Jacob Pan
2022-05-10 21:07   ` Jacob Pan
2022-05-10 23:28   ` Jason Gunthorpe
2022-05-10 23:28     ` Jason Gunthorpe via iommu
2022-05-11  0:43     ` Jacob Pan
2022-05-11  0:43       ` Jacob Pan
2022-05-10 21:07 ` [PATCH v3 3/4] dmaengine: idxd: Use DMA API for in-kernel DMA with PASID Jacob Pan
2022-05-10 21:07   ` Jacob Pan
2022-05-10 21:07 ` [PATCH v3 4/4] iommu/vt-d: Delete unused SVM flag Jacob Pan
2022-05-10 21:07   ` Jacob Pan

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=20220511115427.GU49344@nvidia.com \
    --to=jgg@nvidia.com \
    --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=eric.auger@redhat.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jean-philippe@linaro.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.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.