public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Sairaj Kodilkar <sarunkod@amd.com>
Cc: "Suthikulpanit, Suravee" <suravee.suthikulpanit@amd.com>,
	nicolinc@nvidia.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, joao.m.martins@oracle.com,
	alejandro.j.jimenez@oracle.com
Subject: Re: [PATCH v2 10/12] iommu/amd: Add support for nested domain allocation
Date: Thu, 9 Oct 2025 11:34:48 -0300	[thread overview]
Message-ID: <20251009143448.GB3839422@nvidia.com> (raw)
In-Reply-To: <bff5f16e-ea25-4c59-96de-8002373f17c0@amd.com>

On Thu, Oct 09, 2025 at 11:52:23AM +0530, Sairaj Kodilkar wrote:
> 
> 
> On 10/8/2025 5:09 AM, Jason Gunthorpe wrote:
> > On Tue, Oct 07, 2025 at 03:36:58PM -0500, Suthikulpanit, Suravee wrote:
> > > The gDTE[DomainID] field contains guest Domain ID (gDomID). The host IOMMU
> > > driver uses the gDomId and guest ID (gid) to index the Domain ID mapping
> > > table, and store the host Domain ID (hDomID) in the table entry. This data
> > > structure is required by hw to translation gDomID->hDomID to virtualize
> > > guest invalidation command. This will be part of the upcoming series to
> > > enable hw-vIOMMU.
> > Sure, this translation is part of viommu
> > 
> > > This ndom->id is the hDomID, which is currently allocated per-device to
> > > avoid TLB aliasing i.e. A guest w/ multiple pass-through devices w/ the same
> > > hDomID (same stage 2 table) and different stage-1 tables with same PASID.
> > > IOMMU would use the same TLB tag, which results in TLB aliasing issue.
> > > Therefore, we workaround the issue by allocating per-device hDomID for
> > > nested domain.
> > But this is what I mean here, the gDomId should be 1:1 with the hDomId
> > and here you are making it 1:N.
> Hi Jason,
> The guest will only see V2 page table when we are using hardware vIOMMU.

??

This patch is about adding the gDTE support to the driver and the GDTE
is the mechanism for userspace to inform the kernel about the V2 page
table in the guest.

If the idea at this point is to not support V2 page table then have
this function validate the gDTE to exclude it.

> Since IOMMU driver allocates per device domains when it is using V2
> page table, the mappings are still N:N and invalidations will work
> similar to V2 page table mode in host.

I don't see how this can work. Invalidations will be pushed by the
guest kernel directly to the HW invalidation queue using the
gDOMID. That must translate to a single hDOMID to invalidate the right
stuff.

If there is a hDOMID per device it cannot work unless the guest is
also making per-device IDs.

But we can't make this assumption in the viommu code.

So you must not do this, the gDOMID must be mapped to exactly one
hDOMID, and the viommu object should be managing this. When attaching
a gDTE the kernel should validate that the gDOMID maps to a hDOMID
that has the same V1 page table.

Jason


  parent reply	other threads:[~2025-10-09 14:35 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-01  6:09 [PATCH v2 00/12] iommu/amd: Introduce Nested Translation support Suravee Suthikulpanit
2025-10-01  6:09 ` [PATCH v2 01/12] iommu/amd: Rename DEV_DOMID_MASK to DTE_DOMID_MASK Suravee Suthikulpanit
2025-10-02 17:12   ` Nicolin Chen
2025-10-06 14:36   ` Jason Gunthorpe
2025-10-01  6:09 ` [PATCH v2 02/12] iommu/amd: Make amd_iommu_pdom_id_alloc() non-static Suravee Suthikulpanit
2025-10-02 17:12   ` Nicolin Chen
2025-10-01  6:09 ` [PATCH v2 03/12] iommu/amd: Make amd_iommu_pdom_id_free() non-static Suravee Suthikulpanit
2025-10-02 17:13   ` Nicolin Chen
2025-10-06 14:37   ` Jason Gunthorpe
2025-10-01  6:09 ` [PATCH v2 04/12] iommu/amd: Make amd_iommu_device_flush_dte() non-static Suravee Suthikulpanit
2025-10-02 17:14   ` Nicolin Chen
2025-10-06 14:37   ` Jason Gunthorpe
2025-10-01  6:09 ` [PATCH v2 05/12] iommu/amd: Make amd_iommu_update_dte256() non-static Suravee Suthikulpanit
2025-10-02 17:15   ` Nicolin Chen
2025-10-01  6:09 ` [PATCH v2 06/12] iommu/amd: Make amd_iommu_make_clear_dte() non-static inline Suravee Suthikulpanit
2025-10-02 17:17   ` Nicolin Chen
2025-10-01  6:09 ` [PATCH v2 07/12] iommu/amd: Make amd_iommu_completion_wait() non-static Suravee Suthikulpanit
2025-10-02 17:24   ` Nicolin Chen
2025-10-01  6:09 ` [PATCH v2 08/12] iommufd: Introduce data struct for AMD nested domain allocation Suravee Suthikulpanit
2025-10-02 17:31   ` Nicolin Chen
2025-10-01  6:09 ` [PATCH v2 09/12] iommu/amd: Add support for nest parent " Suravee Suthikulpanit
2025-10-02 18:00   ` Nicolin Chen
2025-10-06 14:43     ` Jason Gunthorpe
2025-10-08 14:16     ` Suthikulpanit, Suravee
2025-10-01  6:09 ` [PATCH v2 10/12] iommu/amd: Add support for nested " Suravee Suthikulpanit
2025-10-02 18:29   ` Nicolin Chen
2025-10-06 14:49   ` Jason Gunthorpe
2025-10-07 20:36     ` Suthikulpanit, Suravee
2025-10-07 23:39       ` Jason Gunthorpe
2025-10-09  6:22         ` Sairaj Kodilkar
2025-10-09  9:16           ` Sairaj Kodilkar
2025-10-09 14:34           ` Jason Gunthorpe [this message]
2025-10-01  6:09 ` [PATCH v2 11/12] iommu/amd: Add support for nested domain attach/detach Suravee Suthikulpanit
2025-10-02 19:04   ` Nicolin Chen
2025-10-06 14:59   ` Jason Gunthorpe
2025-10-07 19:22     ` Suthikulpanit, Suravee
2025-10-07 23:43       ` Jason Gunthorpe
2025-10-09  7:18         ` Sairaj Kodilkar
2025-10-09 14:35           ` Jason Gunthorpe
2025-10-01  6:09 ` [PATCH v2 12/12] iommu/amd: Introduce IOMMUFD vIOMMU support for AMD Suravee Suthikulpanit
2025-10-02 20:05   ` Nicolin Chen
2025-10-06 15:01     ` 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=20251009143448.GB3839422@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=alejandro.j.jimenez@oracle.com \
    --cc=gptran@google.com \
    --cc=iommu@lists.linux.dev \
    --cc=joao.m.martins@oracle.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=nicolinc@nvidia.com \
    --cc=prashanthpra@google.com \
    --cc=robin.murphy@arm.com \
    --cc=sairaj.arunkodilkar@amd.com \
    --cc=santosh.shukla@amd.com \
    --cc=sarunkod@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox