From: Jason Gunthorpe <jgg@nvidia.com>
To: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: 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 v6 10/13] iommu/amd: Introduce gDomID-to-hDomID Mapping and handle parent domain invalidation
Date: Mon, 19 Jan 2026 13:13:07 -0400 [thread overview]
Message-ID: <20260119171307.GJ1134360@nvidia.com> (raw)
In-Reply-To: <20260115060814.10692-11-suravee.suthikulpanit@amd.com>
On Thu, Jan 15, 2026 at 06:08:11AM +0000, Suravee Suthikulpanit wrote:
> +static int iommu_flush_pages_v1_hdom_ids(struct protection_domain *pdom, u64 address, size_t size)
> +{
> + int ret = 0;
> + struct amd_iommu_viommu *aviommu;
> +
> + list_for_each_entry(aviommu, &pdom->viommu_list, pdom_list) {
> + unsigned long i;
You should have some lockdeps here for this list iteration..
> +static void *gdom_info_load_or_alloc_locked(struct xarray *xa, unsigned long index)
> +{
> + struct guest_domain_mapping_info *elm, *res;
> +
> + elm = xa_load(xa, index);
> + if (elm)
> + return elm;
> +
> + xa_unlock(xa);
> + elm = kzalloc(sizeof(struct guest_domain_mapping_info), GFP_KERNEL);
> + xa_lock(xa);
> + if (!elm)
> + return ERR_PTR(-ENOMEM);
> +
> + res = __xa_cmpxchg(xa, index, NULL, elm, GFP_KERNEL);
> + if (xa_is_err(res))
> + res = ERR_PTR(xa_err(res));
> +
> + if (res) {
> + kfree(elm);
> + return res;
> + }
> +
> + refcount_set(&elm->users, 0);
> + return elm;
> +}
> +
> /*
> * This function is assigned to struct iommufd_viommu_ops.alloc_domain_nested()
> * during the call to struct iommu_ops.viommu_init().
> @@ -68,6 +96,7 @@ amd_iommu_alloc_domain_nested(struct iommufd_viommu *viommu, u32 flags,
> {
> int ret;
> struct nested_domain *ndom;
> + struct guest_domain_mapping_info *gdom_info;
> struct amd_iommu_viommu *aviommu = container_of(viommu, struct amd_iommu_viommu, core);
>
> if (user_data->type != IOMMU_HWPT_DATA_AMD_GUEST)
> @@ -92,7 +121,63 @@ amd_iommu_alloc_domain_nested(struct iommufd_viommu *viommu, u32 flags,
> ndom->domain.type = IOMMU_DOMAIN_NESTED;
> ndom->viommu = aviommu;
>
> + /*
> + * Normally, when a guest has multiple pass-through devices,
> + * the IOMMU driver setup DTEs with the same stage-2 table and
> + * use the same host domain ID (hDomId). In case of nested translation,
> + * if the guest setup different stage-1 tables with same PASID,
> + * IOMMU would use the same TLB tag. This will results in TLB
> + * aliasing issue.
> + *
> + * The guest is assigning gDomIDs based on its own algorithm for managing
> + * cache tags of (DomID, PASID). Within a single viommu, the nest parent domain
> + * (w/ S2 table) is used by all DTEs. But we need to consistently map the gDomID
> + * to a single hDomID. This is done using an xarray in the vIOMMU to
> + * keep track of the gDomID mapping. When the S2 is changed, the INVALIDATE_IOMMU_PAGES
> + * command must be issued for each hDomID in the xarray.
> + */
> + xa_lock(&aviommu->gdomid_array);
> +
> + gdom_info = gdom_info_load_or_alloc_locked(&aviommu->gdomid_array, ndom->gdom_id);
> + if (IS_ERR(gdom_info)) {
> + xa_unlock(&aviommu->gdomid_array);
> + ret = PTR_ERR(gdom_info);
> + goto out_err;
> + }
> +
> + /* Check if gDomID exist */
> + if (refcount_inc_not_zero(&gdom_info->users)) {
> + ndom->gdom_info = gdom_info;
> + xa_unlock(&aviommu->gdomid_array);
This is pretty tortured, the alloc flow inside
gdom_info_load_or_alloc_locked() should do the
amd_iommu_pdom_id_alloc() and set the refcount to 1 before installing
it in the xarray, then you don't need any of this here.
> + /* The gDomID does not exist. We allocate new hdom_id */
> + gdom_info->hdom_id = amd_iommu_pdom_id_alloc();
Then this allocation wouldn't have to be ATOMIC.
But it looks working the way it is so no rush
Jason
next prev parent reply other threads:[~2026-01-19 17:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-15 6:08 [PATCH v6 00/13] iommu/amd: Introduce Nested Translation support Suravee Suthikulpanit
2026-01-15 6:08 ` [PATCH v6 01/13] iommu/amd: Add support for hw_info for iommu capability query Suravee Suthikulpanit
2026-01-15 6:08 ` [PATCH v6 02/13] iommu/amd: Rename DEV_DOMID_MASK to DTE_DOMID_MASK Suravee Suthikulpanit
2026-01-15 6:08 ` [PATCH v6 03/13] iommu/amd: Make amd_iommu_make_clear_dte() non-static inline Suravee Suthikulpanit
2026-01-15 6:08 ` [PATCH v6 04/13] iommu/amd: Introduce helper function amd_iommu_update_dte() Suravee Suthikulpanit
2026-01-15 6:08 ` [PATCH v6 05/13] iommufd: Introduce data struct for AMD nested domain allocation Suravee Suthikulpanit
2026-01-15 6:08 ` [PATCH v6 06/13] iommu/amd: Always enable GCR3TRPMode when supported Suravee Suthikulpanit
2026-01-15 6:08 ` [PATCH v6 07/13] iommu/amd: Add support for nest parent domain allocation Suravee Suthikulpanit
2026-01-15 6:08 ` [PATCH v6 08/13] iommu/amd: Introduce struct amd_iommu_viommu Suravee Suthikulpanit
2026-01-15 6:08 ` [PATCH v6 09/13] iommu/amd: Add support for nested domain allocation Suravee Suthikulpanit
2026-01-15 6:08 ` [PATCH v6 10/13] iommu/amd: Introduce gDomID-to-hDomID Mapping and handle parent domain invalidation Suravee Suthikulpanit
2026-01-19 17:13 ` Jason Gunthorpe [this message]
2026-01-15 6:08 ` [PATCH v6 11/13] iommu/amd: Refactor persistent DTE bits programming into amd_iommu_make_clear_dte() Suravee Suthikulpanit
2026-01-15 6:08 ` [PATCH v6 12/13] iommu/amd: Refactor logic to program the host page table in DTE Suravee Suthikulpanit
2026-01-15 6:08 ` [PATCH v6 13/13] iommu/amd: Add support for nested domain attach/detach Suravee Suthikulpanit
2026-01-19 17:15 ` Jason Gunthorpe
2026-01-18 9:56 ` [PATCH v6 00/13] iommu/amd: Introduce Nested Translation support Jörg Rödel
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=20260119171307.GJ1134360@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=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