All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Suthikulpanit, Suravee" <suravee.suthikulpanit@amd.com>
Cc: linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
	joro@8bytes.org, yi.l.liu@intel.com, kevin.tian@intel.com,
	nicolinc@nvidia.com, vasant.hegde@amd.com, jon.grimm@amd.com,
	santosh.shukla@amd.com, Sairaj.K@amd.com, jay.chen@amd.com,
	Ming.Shu@amd.com, SooJin.Tan@amd.com, chrisl@kernel.org,
	wvw@google.com, wnliu@google.com, dantuluris@google.com,
	kpsingh@google.com, alejandro.j.jimenez@oracle.com,
	joao.m.martins@oracle.com, guanghuifeng@linux.alibaba.com
Subject: Re: [PATCH v6 18/24] iommu/amd: Init and clear vIOMMU DevID and DomID maps
Date: Tue, 20 Oct 2026 13:50:58 -0300	[thread overview]
Message-ID: <20261020165058.GF3008132@nvidia.com> (raw)
In-Reply-To: <9043514a-932e-436a-805d-9694b88d9caf@amd.com>

On Tue, Oct 20, 2026 at 11:00:25PM +0700, Suthikulpanit, Suravee wrote:
> 
> 
> On 10/16/2026 6:39 AM, Jason Gunthorpe wrote:
> > > Before using a vIOMMU instance, prefill the mapping tables so hardware
> > > never sees an unknown guest ID. Map every gdom_id to the nest parent
> > > domain ID, and write every gdev_id with hdev_id 0. Init cannot be
> > > scoped to IDs in use; INVALIDATE_IOMMU_ALL walks the HW table.
> > > 
> > > Yield vfctrl_lock every 256 doorbells so the 128K MMIO loop can
> > > resched. Attach cannot run until viommu->ops is set after init_one().
> > > 
> > > On destroy, drain CONTROL0/CONTROL1 WRITE and unmap. Do not rewrite
> > > the full tables: that would start 128K DMA writes into pages about
> > > to be freed. vDevice destroy and nested_domain_free already restored
> > > idle entries.
> > > 
> > > Skip VFCTRL access when CONTROL_CMDBUF_EN is already clear, matching
> > > viommu_priv_unmap_free() on the same uninit_one() path.
> > I didn't see any explanation what happens if the guest issues an
> > invalidate to a gdomid without a host domid?
> > 
> > This is related to my questions about when the IOTLB is cleaned. Given
> > this patch I would expect that once the mapping is removed the hdomid
> > is cleaned and any invalidations for the gdomid are NOPd
> > 
> > If the gdomis is used again it is assigned to a clean hdomid and those
> > NOP'd invalidations don't matter.
> > 
> > Is this how it works?
> 
> When guest sends INVALIDATE_IOMMU_PAGES command with gDomID to vCmd buffer,
> IOMMU hardware uses the gDomID to index the DomainID mapping table to get
> the hDomID (from the entry w/ v=1). Then it uses the hDomID  for actual
> IOMMU TLB invalidation. If the mapping entry has v=0, it would generate
> hardware error in the host Event log.
> 
> If the hDomID does not match anything in the IOMMU TLB, it would be a NOP.
> This is the same as when host IOMMU driver submit INVALIDATE_IOMMU_PAGES
> command w/ an unused domainID.
> 
> For current implementation, the IOMMU driver prefills the DomainID mapping
> table with nest parent domain ID (hDomID), and restore the same ID when
> mapping is removed. This is to make sure that each mapping entry has valid
> hDomID and not just some random domain ID.

I asked what happens if the gDomID hits an entry with V=0 ?

Presumably something bad to motivate all this extra work.

Jason

  reply	other threads:[~2026-10-20 16:51 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-30  9:23 [PATCH v6 00/24] iommu/amd: Introduce AMD Hardware-accelerated Virtualized IOMMU (vIOMMU) Support Suravee Suthikulpanit
2026-09-30  9:23 ` [PATCH v6 01/24] iommu/amd: Introduce vIOMMU-specific events and event Suravee Suthikulpanit
2026-09-30  9:23 ` [PATCH v6 02/24] iommu/amd: Introduce EVENT_TYPE_GUEST_EVENT_FAULT Suravee Suthikulpanit
2026-10-19  6:10   ` Vasant Hegde
2026-09-30  9:23 ` [PATCH v6 03/24] iommu/amd: Detect and initialize AMD vIOMMU feature Suravee Suthikulpanit
2026-10-19  6:40   ` Vasant Hegde
2026-09-30  9:23 ` [PATCH v6 04/24] iommu/amd: Introduce IOMMUFD vIOMMU support for AMD Suravee Suthikulpanit
2026-09-30 21:44   ` Nicolin Chen
2026-09-30  9:23 ` [PATCH v6 05/24] iommu/amd: Allocate Guest IDs for IOMMUFD vIOMMU instances Suravee Suthikulpanit
2026-10-19 11:15   ` Vasant Hegde
2026-09-30  9:23 ` [PATCH v6 06/24] iommu/amd: Map vIOMMU VF and VF Control MMIO BARs Suravee Suthikulpanit
2026-10-19 11:28   ` Vasant Hegde
2026-10-19 17:06   ` Vasant Hegde
2026-09-30  9:23 ` [PATCH v6 07/24] iommu/amd: Add support for AMD vIOMMU VF MMIO region Suravee Suthikulpanit
2026-10-19 11:38   ` Vasant Hegde
2026-09-30  9:23 ` [PATCH v6 08/24] iommu/amd: Introduce Reset vMMIO Command Suravee Suthikulpanit
2026-09-30  9:23 ` [PATCH v6 09/24] iommu/amd: Introduce and map vIOMMU private IPA region Suravee Suthikulpanit
2026-10-19 14:06   ` Vasant Hegde
2026-09-30  9:23 ` [PATCH v6 10/24] iommu/amd: Pass iommu to device_flush_dte() Suravee Suthikulpanit
2026-10-19 17:14   ` Vasant Hegde
2026-09-30  9:23 ` [PATCH v6 11/24] iommu/amd: Pass iommu and devid to amd_iommu_make_clear_dte() Suravee Suthikulpanit
2026-09-30  9:23 ` [PATCH v6 12/24] iommu/amd: Store per-segment iommu_dev_data in an xarray Suravee Suthikulpanit
2026-10-19 13:39   ` Vasant Hegde
2026-09-30  9:23 ` [PATCH v6 13/24] iommu/amd: Program IOMMU DTE with the private IPA domain Suravee Suthikulpanit
2026-10-19 16:58   ` Vasant Hegde
2026-09-30  9:23 ` [PATCH v6 14/24] iommu/amd: Add per-VM private IPA alloc/map helpers Suravee Suthikulpanit
2026-09-30  9:23 ` [PATCH v6 15/24] iommu/amd: Add helper functions to manage DevID / DomID mapping tables Suravee Suthikulpanit
2026-09-30  9:23 ` [PATCH v6 16/24] iommu/amd: Add IOMMUFD vDevice and DevID mapping Suravee Suthikulpanit
2026-10-15 23:39   ` Jason Gunthorpe
2026-09-30  9:23 ` [PATCH v6 17/24] iommu/amd: Program nested DTE and DomID map on attach Suravee Suthikulpanit
2026-10-15 23:39   ` Jason Gunthorpe
2026-09-30  9:23 ` [PATCH v6 18/24] iommu/amd: Init and clear vIOMMU DevID and DomID maps Suravee Suthikulpanit
2026-10-15 23:39   ` Jason Gunthorpe
2026-10-20 16:00     ` Suthikulpanit, Suravee
2026-10-20 16:50       ` Jason Gunthorpe [this message]
2026-09-30  9:23 ` [PATCH v6 19/24] iommu/amd: Add per-segment translate device ID pool Suravee Suthikulpanit
2026-09-30  9:23 ` [PATCH v6 20/24] iommu/amd: Reserve translate-device-id for PCI requestor aliases Suravee Suthikulpanit
2026-09-30  9:23 ` [PATCH v6 21/24] iommu/amd: Add translation DTE and VFctrl TransDevID helpers Suravee Suthikulpanit
2026-09-30  9:23 ` [PATCH v6 22/24] iommu/amd: Add translate-device-id alloc/free with vIOMMU owner Suravee Suthikulpanit
2026-09-30  9:23 ` [PATCH v6 23/24] iommu/amd: Assign per-vIOMMU translate device ID Suravee Suthikulpanit
2026-09-30  9:23 ` [PATCH v6 24/24] iommu/amd: Relocate vIOMMU translate-device-id on PCI reserve Suravee Suthikulpanit
2026-10-15 12:33 ` [PATCH v6 00/24] iommu/amd: Introduce AMD Hardware-accelerated Virtualized IOMMU (vIOMMU) Support Guixin Liu

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=20261020165058.GF3008132@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=Ming.Shu@amd.com \
    --cc=Sairaj.K@amd.com \
    --cc=SooJin.Tan@amd.com \
    --cc=alejandro.j.jimenez@oracle.com \
    --cc=chrisl@kernel.org \
    --cc=dantuluris@google.com \
    --cc=guanghuifeng@linux.alibaba.com \
    --cc=iommu@lists.linux.dev \
    --cc=jay.chen@amd.com \
    --cc=joao.m.martins@oracle.com \
    --cc=jon.grimm@amd.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kpsingh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=santosh.shukla@amd.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=vasant.hegde@amd.com \
    --cc=wnliu@google.com \
    --cc=wvw@google.com \
    --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.