All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Raj, Ashok" <ashok.raj@intel.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
	Joerg Roedel <joro@8bytes.org>,
	Christoph Hellwig <hch@infradead.org>,
	Kevin Tian <kevin.tian@intel.com>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.com>,
	Dave Jiang <dave.jiang@intel.com>, Vinod Koul <vkoul@kernel.org>,
	Eric Auger <eric.auger@redhat.com>, Liu Yi L <yi.l.liu@intel.com>,
	Jacob jun Pan <jacob.jun.pan@intel.com>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	Jean-Philippe Brucker <jean-philippe@linaro.org>
Subject: Re: [PATCH v8 01/11] iommu: Add max_pasids field in struct iommu_device
Date: Thu, 9 Jun 2022 20:53:03 -0300	[thread overview]
Message-ID: <20220609235303.GC1343366@nvidia.com> (raw)
In-Reply-To: <20220609172542.GB33363@araj-dh-work>

On Thu, Jun 09, 2022 at 05:25:42PM +0000, Raj, Ashok wrote:
> 
> On Tue, Jun 07, 2022 at 09:49:32AM +0800, Lu Baolu wrote:
> > Use this field to keep the number of supported PASIDs that an IOMMU
> > hardware is able to support. This is a generic attribute of an IOMMU
> > and lifting it into the per-IOMMU device structure makes it possible
> 
> There is also a per-device attribute that tells what width is supported on
> each device. When a device enables SVM, for simplicity we were proposing to
> disable SVM on devices that don't support the full width, since it adds
> additional complexity on the allocation interface. Is that factored into
> this?

I would like to see the concept of a 'global PASID' and this is the
only place we'd union all the per-device limits together. SVM can
optionally use a global PASID and ENQCMD requires it, but I don't want
to see the core code assuming everything is ENQCMD.

Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe via iommu <iommu@lists.linux-foundation.org>
To: "Raj, Ashok" <ashok.raj@intel.com>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Kevin Tian <kevin.tian@intel.com>,
	Dave Jiang <dave.jiang@intel.com>, Will Deacon <will@kernel.org>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	Jean-Philippe Brucker <jean-philippe@linaro.com>,
	Vinod Koul <vkoul@kernel.org>,
	Jacob jun Pan <jacob.jun.pan@intel.com>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v8 01/11] iommu: Add max_pasids field in struct iommu_device
Date: Thu, 9 Jun 2022 20:53:03 -0300	[thread overview]
Message-ID: <20220609235303.GC1343366@nvidia.com> (raw)
In-Reply-To: <20220609172542.GB33363@araj-dh-work>

On Thu, Jun 09, 2022 at 05:25:42PM +0000, Raj, Ashok wrote:
> 
> On Tue, Jun 07, 2022 at 09:49:32AM +0800, Lu Baolu wrote:
> > Use this field to keep the number of supported PASIDs that an IOMMU
> > hardware is able to support. This is a generic attribute of an IOMMU
> > and lifting it into the per-IOMMU device structure makes it possible
> 
> There is also a per-device attribute that tells what width is supported on
> each device. When a device enables SVM, for simplicity we were proposing to
> disable SVM on devices that don't support the full width, since it adds
> additional complexity on the allocation interface. Is that factored into
> this?

I would like to see the concept of a 'global PASID' and this is the
only place we'd union all the per-device limits together. SVM can
optionally use a global PASID and ENQCMD requires it, but I don't want
to see the core code assuming everything is ENQCMD.

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

  reply	other threads:[~2022-06-09 23:53 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-07  1:49 [PATCH v8 00/11] iommu: SVA and IOPF refactoring Lu Baolu
2022-06-07  1:49 ` Lu Baolu
2022-06-07  1:49 ` [PATCH v8 01/11] iommu: Add max_pasids field in struct iommu_device Lu Baolu
2022-06-07  1:49   ` Lu Baolu
2022-06-09 17:25   ` Raj, Ashok
2022-06-09 17:25     ` Raj, Ashok
2022-06-09 23:53     ` Jason Gunthorpe [this message]
2022-06-09 23:53       ` Jason Gunthorpe via iommu
2022-06-10  8:45       ` Tian, Kevin
2022-06-10  8:45         ` Tian, Kevin
2022-06-10  6:33     ` Baolu Lu
2022-06-10  6:33       ` Baolu Lu
2022-06-07  1:49 ` [PATCH v8 02/11] iommu: Add max_pasids field in struct dev_iommu Lu Baolu
2022-06-07  1:49   ` Lu Baolu
2022-06-09 19:01   ` Raj, Ashok
2022-06-09 19:01     ` Raj, Ashok
2022-06-10  6:46     ` Baolu Lu
2022-06-10  6:46       ` Baolu Lu
2022-06-10  9:01       ` Tian, Kevin
2022-06-10  9:01         ` Tian, Kevin
2022-06-10  9:07         ` Baolu Lu
2022-06-10  9:07           ` Baolu Lu
2022-06-07  1:49 ` [PATCH v8 03/11] iommu: Remove SVM_FLAG_SUPERVISOR_MODE support Lu Baolu
2022-06-07  1:49   ` Lu Baolu
2022-06-07  1:49 ` [PATCH v8 04/11] iommu: Add sva iommu_domain support Lu Baolu
2022-06-07  1:49   ` Lu Baolu
2022-06-09 20:25   ` Raj, Ashok
2022-06-09 20:25     ` Raj, Ashok
2022-06-10  7:16     ` Baolu Lu
2022-06-10  7:16       ` Baolu Lu
2022-06-17  7:43       ` Tian, Kevin
2022-06-17  7:43         ` Tian, Kevin
2022-06-20  0:34         ` Baolu Lu
2022-06-20  0:34           ` Baolu Lu
2022-06-07  1:49 ` [PATCH v8 05/11] iommu/vt-d: Add SVA domain support Lu Baolu
2022-06-07  1:49   ` Lu Baolu
2022-06-17  7:47   ` Tian, Kevin
2022-06-17  7:47     ` Tian, Kevin
2022-06-20  0:35     ` Baolu Lu
2022-06-20  0:35       ` Baolu Lu
2022-06-07  1:49 ` [PATCH v8 06/11] arm-smmu-v3/sva: " Lu Baolu
2022-06-07  1:49   ` Lu Baolu
2022-06-07  1:49 ` [PATCH v8 07/11] iommu/sva: Refactoring iommu_sva_bind/unbind_device() Lu Baolu
2022-06-07  1:49   ` Lu Baolu
2022-06-07  1:49 ` [PATCH v8 08/11] iommu: Remove SVA related callbacks from iommu ops Lu Baolu
2022-06-07  1:49   ` Lu Baolu
2022-06-07  1:49 ` [PATCH v8 09/11] iommu: Prepare IOMMU domain for IOPF Lu Baolu
2022-06-07  1:49   ` Lu Baolu
2022-06-07  1:49 ` [PATCH v8 10/11] iommu: Per-domain I/O page fault handling Lu Baolu
2022-06-07  1:49   ` Lu Baolu
2022-06-07  1:49 ` [PATCH v8 11/11] iommu: Rename iommu-sva-lib.{c,h} Lu Baolu
2022-06-07  1:49   ` Lu Baolu

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=20220609235303.GC1343366@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=dave.jiang@intel.com \
    --cc=eric.auger@redhat.com \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@intel.com \
    --cc=jean-philippe@linaro.com \
    --cc=jean-philippe@linaro.org \
    --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.