From: Vasant Hegde <vasant.hegde@amd.com>
To: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
joro@8bytes.org, jgg@nvidia.com
Cc: yi.l.liu@intel.com, kevin.tian@intel.com, nicolinc@nvidia.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 13/24] iommu/amd: Program IOMMU DTE with the private IPA domain
Date: Mon, 19 Oct 2026 22:28:58 +0530 [thread overview]
Message-ID: <99d50810-b040-4162-bf7c-e782beeaac8f@amd.com> (raw)
In-Reply-To: <20260930092344.5616-14-suravee.suthikulpanit@amd.com>
On 9/30/2026 2:53 PM, Suravee Suthikulpanit wrote:
> The IOMMU PCI function does not go through the normal device attach
> path, so it has no iommu_dev_data. Add amd_iommu_alloc_dev_data()
> and amd_iommu_free_dev_data() for a synthetic object that is not
> interned in pci_seg->dev_data_xa. Program that DTE with the private
> IPA domain's v1 page table so the IOMMU can DMA to its own vIOMMU
> backing store.
>
> Leave the synthetic DTE off pdom->dev_list and with no struct
> device so clone_aliases() is skipped; it is only iommu->devid.
> Rewrite it from amd_iommu_change_top() when the IPA table grows
> so later high maps remain reachable.
>
> Do this after viommu_private_space_init() so viommu_pdom exists.
> On teardown, clear the DTE only while CONTROL_CMDBUF_EN is set,
> then free the object. After disable_iommus() the INV_DTE flush
> would time out, so skip it and still free the object. Failed
> self DTE allocation unwinds through amd_viommu_uninit().
>
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> ---
> drivers/iommu/amd/amd_iommu.h | 4 ++
> drivers/iommu/amd/amd_iommu_types.h | 2 +
> drivers/iommu/amd/init.c | 7 +-
> drivers/iommu/amd/iommu.c | 102 +++++++++++++++++++++++++---
> drivers/iommu/amd/viommu.c | 57 ++++++++++++++++
> 5 files changed, 161 insertions(+), 11 deletions(-)
>
.../...
> +
> +static bool viommu_cmdbuf_enabled(struct amd_iommu *iommu);
> +
> +static void viommu_free_self_dev_data(struct amd_iommu *iommu)
> +{
> + struct iommu_dev_data *dev_data = iommu->viommu_dev_data;
> + struct dev_table_entry new = {};
> +
> + if (!dev_data)
> + return;
> +
> + /*
> + * INV_DTE needs the command buffer. Skip it after
> + * disable_iommus() clears CONTROL_CMDBUF_EN. The init
> + * unwind still flushes while the buffer is enabled.
> + */
> + if (viommu_cmdbuf_enabled(iommu)) {
As mentioned in previous patch, do we really need this check?
> + amd_iommu_make_clear_dte(iommu, dev_data->devid, &new);
> + amd_iommu_update_dte(iommu, dev_data, &new);
> + }
> + amd_iommu_free_dev_data(iommu, dev_data);
> + iommu->viommu_dev_data = NULL;
> +}
> +
> +static int viommu_alloc_self_dev_data(struct amd_iommu *iommu)
> +{
> + struct protection_domain *pdom = iommu->viommu_pdom;
> + struct pt_iommu_amdv1_hw_info pt_info;
> + struct iommu_dev_data *dev_data;
> + struct dev_table_entry new = {};
> +
> + dev_data = amd_iommu_alloc_dev_data(iommu->devid);
I am not getting why we can't call allc_dev_data? So that we can track these
devid (including translation devid) in dev_data_xa. So that we can catch
duplicate allocations?
> + if (!dev_data) {
> + pr_err("%s: Failed to allocate dev_data\n", __func__);
> + return -ENOMEM;
> + }
> + /*
> + * Synthetic DTE for iommu->devid only: no struct device, so
> + * amd_iommu_update_dte() skips clone_aliases(), and not on
> + * pdom->dev_list (not an IOMMU-API attach).
> + */
> + dev_data->dev = NULL;
I am not able to figureout why we cannot track iommu device structure here. Does
it mess up anything? if we hook this to pdom->dev_list then we don't need
special update_viommu_self_dte().
-Vasant
next prev parent reply other threads:[~2026-10-19 16:59 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 [this message]
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
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=99d50810-b040-4162-bf7c-e782beeaac8f@amd.com \
--to=vasant.hegde@amd.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=jgg@nvidia.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=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.