All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	<linux-kernel@vger.kernel.org>, <robin.murphy@arm.com>,
	<will@kernel.org>, <joro@8bytes.org>, <kevin.tian@intel.com>,
	<jsnitsel@redhat.com>, <vasant.hegde@amd.com>,
	<iommu@lists.linux.dev>, <santosh.shukla@amd.com>,
	<sairaj.arunkodilkar@amd.com>, <jon.grimm@amd.com>,
	<prashanthpra@google.com>, <wvw@google.com>, <wnliu@google.com>,
	<gptran@google.com>, <kpsingh@google.com>
Subject: Re: [PATCH 7/8] iommu/amd: Add support for nested domain allocation
Date: Fri, 22 Aug 2025 14:45:58 -0700	[thread overview]
Message-ID: <aKjlFt80ltp3mjcp@Asurada-Nvidia> (raw)
In-Reply-To: <20250822211618.GF1405994@nvidia.com>

On Fri, Aug 22, 2025 at 06:16:18PM -0300, Jason Gunthorpe wrote:
> On Fri, Aug 22, 2025 at 12:51:02PM -0700, Nicolin Chen wrote:
> > > @@ -3113,6 +3116,7 @@ const struct iommu_ops amd_iommu_ops = {
> > >  	.release_domain = &release_domain,
> > >  	.identity_domain = &identity_domain.domain,
> > >  	.domain_alloc_paging_flags = amd_iommu_domain_alloc_paging_flags,
> > > +	.domain_alloc_nested = amd_iommu_domain_alloc_nested,
> > >  	.domain_alloc_sva = amd_iommu_domain_alloc_sva,
> > >  	.probe_device = amd_iommu_probe_device,
> > >  	.release_device = amd_iommu_release_device,
> > 
> > This will be an HWPT-based nesting support, v.s. vIOMMU-based.
> > 
> > If AMD wants to enable its Command/Event Buffers, I think this
> > should follow the vIOMMU model instead.
> 
> I've been expecting drivers to do both, like ARM.. Nested is the basic
> infrastructure and then the viommu changes what domain id nested will
> use similar to how ARM constrains the VMID based on the viommu.

Hmm, we haven't implemented both in ARM but only the vIOMMU-based
one..

Yea, AMD could start with the HWPT-based one, but that would need
an invalidation op(?), which seems missing in this series. So, to
support direct invalidation via Command Buffers, vIOMMU should be
the only option, right?

Nicolin

  reply	other threads:[~2025-08-22 21:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-20 11:30 [PATCH 0/8] iommu/amd: Introduce Nested Translation support Suravee Suthikulpanit
2025-08-20 11:30 ` [PATCH 1/8] iommu/amd: Make amd_iommu_pdom_id_alloc() non-static Suravee Suthikulpanit
2025-09-02 13:03   ` Jason Gunthorpe
2025-08-20 11:30 ` [PATCH 2/8] iommu/amd: Making device attach / detach helpers non-static Suravee Suthikulpanit
2025-09-02 13:10   ` Jason Gunthorpe
2025-08-20 11:30 ` [PATCH 3/8] iommu/amd: Making amd_iommu_pdev_enable_cap_ats non-static Suravee Suthikulpanit
2025-08-20 11:30 ` [PATCH 4/8] iommu/amd: Introduce struct gcr3_tbl_info.giov Suravee Suthikulpanit
2025-09-02 13:07   ` Jason Gunthorpe
2025-08-20 11:30 ` [PATCH 5/8] iommufd: Introduce data struct for AMD nested domain allocation Suravee Suthikulpanit
2025-09-02 13:09   ` Jason Gunthorpe
2025-08-20 11:30 ` [PATCH 6/8] iommu/amd: Add support for nest parent " Suravee Suthikulpanit
2025-09-02 13:12   ` Jason Gunthorpe
2025-08-20 11:30 ` [PATCH 7/8] iommu/amd: Add support for nested " Suravee Suthikulpanit
2025-08-22  5:39   ` kernel test robot
2025-08-22 19:51   ` Nicolin Chen
2025-08-22 21:16     ` Jason Gunthorpe
2025-08-22 21:45       ` Nicolin Chen [this message]
2025-08-25 13:38         ` Jason Gunthorpe
2025-09-01  7:09   ` Sairaj Kodilkar
2025-09-02 11:42     ` Jason Gunthorpe
2025-09-02 13:18   ` Jason Gunthorpe
2025-08-20 11:30 ` [PATCH 8/8] iommu/amd: Add support for nested domain attach/detach Suravee Suthikulpanit
2025-08-22 20:20   ` Nicolin Chen
2025-08-28  0:36     ` Suthikulpanit, Suravee
2025-09-02 13:25   ` Jason Gunthorpe
2025-09-03  8:27   ` Sairaj Kodilkar

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=aKjlFt80ltp3mjcp@Asurada-Nvidia \
    --to=nicolinc@nvidia.com \
    --cc=gptran@google.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=jon.grimm@amd.com \
    --cc=joro@8bytes.org \
    --cc=jsnitsel@redhat.com \
    --cc=kevin.tian@intel.com \
    --cc=kpsingh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prashanthpra@google.com \
    --cc=robin.murphy@arm.com \
    --cc=sairaj.arunkodilkar@amd.com \
    --cc=santosh.shukla@amd.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=vasant.hegde@amd.com \
    --cc=will@kernel.org \
    --cc=wnliu@google.com \
    --cc=wvw@google.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.