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 21/24] iommu/amd: Add translation DTE and VFctrl TransDevID helpers
Date: Wed, 21 Oct 2026 11:45:51 +0530 [thread overview]
Message-ID: <75e9510f-1dfb-4c59-b2db-48feda7631c1@amd.com> (raw)
In-Reply-To: <20260930092344.5616-22-suravee.suthikulpanit@amd.com>
On 9/30/2026 2:53 PM, Suravee Suthikulpanit wrote:
> vIOMMU GPA->SPA walks use a per-vIOMMU TransDevID: VFCTRL guest-misc
> names the slot, and that host DTE points at the nest-parent v1 table.
>
> Add amd_iommu_set_translate_dte() and amd_iommu_clear_translate_dte()
> to program that DTE, owned on amd_iommu_viommu.trans_dev_data rather
> than pci_seg->dev_data_xa. Rewrite it from amd_iommu_change_top() via
> pdom->viommu_list when the nest-parent table grows.
>
> Add amd_iommu_update_vfctrl_mmio_translate_devid() to publish the
> TransDevID in VFCTRL guest-misc MMIO.
>
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> ---
> drivers/iommu/amd/amd_iommu.h | 7 ++
> drivers/iommu/amd/amd_iommu_types.h | 4 +
> drivers/iommu/amd/iommu.c | 153 ++++++++++++++++++++++++----
> 3 files changed, 142 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
> index 6ac64524208b..4aede6f6d489 100644
> --- a/drivers/iommu/amd/amd_iommu.h
> +++ b/drivers/iommu/amd/amd_iommu.h
> @@ -213,6 +213,13 @@ void amd_iommu_update_dte(struct amd_iommu *iommu,
> struct iommu_dev_data *dev_data,
> struct dev_table_entry *new);
>
> +int amd_iommu_set_translate_dte(struct iommufd_viommu *viommu);
> +void amd_iommu_clear_translate_dte(struct amd_iommu *iommu,
> + struct iommu_dev_data *dev_data,
> + u16 trans_devid);
> +void amd_iommu_update_vfctrl_mmio_translate_devid(struct amd_iommu *iommu,
> + u16 gid, u32 trans_devid);
> +
> static inline void
> amd_iommu_make_clear_dte(struct amd_iommu *iommu, u16 devid,
> struct dev_table_entry *new)
> diff --git a/drivers/iommu/amd/amd_iommu_types.h b/drivers/iommu/amd/amd_iommu_types.h
> index 6b3a43952797..5f84f25e3f37 100644
> --- a/drivers/iommu/amd/amd_iommu_types.h
> +++ b/drivers/iommu/amd/amd_iommu_types.h
> @@ -489,6 +489,7 @@ extern bool amdr_ivrs_remap_support;
> /* VIOMMU stuff */
> #define VIOMMU_VF_MMIO_ENTRY_SIZE 4096
> #define VIOMMU_VFCTRL_MMIO_ENTRY_SIZE 64
> +#define VIOMMU_VFCTRL_GUEST_MISC_CONTROL_OFFSET 0x10
>
> /* Host ioremap/request_mem_region sizes for VF / VF_CNTL BARs */
> #define VIOMMU_VF_MMIO_MAP_SIZE 0x10000000UL
> @@ -551,6 +552,9 @@ struct amd_iommu_viommu {
>
> u64 *devid_table;
> u64 *domid_table;
> + u16 trans_devid;
> + /* Synthetic DTE; not stored in pci_seg->dev_data_xa */
> + struct iommu_dev_data *trans_dev_data;
>
> /*
> * Serializes VFCTRL Guest DID map CONTROL0/CONTROL1 doorbells
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 65550b070a12..8943863105b6 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -148,11 +148,11 @@ static void write_dte_lower128(struct dev_table_entry *ptr, struct dev_table_ent
> * So, only consider control bits related to DMA when updating the entry.
> */
> static void update_dte256(struct amd_iommu *iommu, struct iommu_dev_data *dev_data,
> - struct dev_table_entry *new)
> + u16 devid, struct dev_table_entry *new)
Why this change? dev_data always contains devid right?
> {
> unsigned long flags;
> struct dev_table_entry *dev_table = get_dev_table(iommu);
> - struct dev_table_entry *ptr = &dev_table[dev_data->devid];
> + struct dev_table_entry *ptr = &dev_table[devid];
>
> spin_lock_irqsave(&dev_data->dte_lock, flags);
.../...
> */
> static void update_viommu_self_dte(struct protection_domain *pdom,
> phys_addr_t top_paddr,
> unsigned int top_level)
> {
> struct pdom_iommu_info *pdom_iommu_info;
> + struct amd_iommu_viommu *aviommu;
> unsigned long i;
>
> lockdep_assert_held(&pdom->lock);
> @@ -2884,6 +2893,17 @@ static void update_viommu_self_dte(struct protection_domain *pdom,
> set_dte_entry(iommu, iommu->viommu_dev_data, top_paddr,
> top_level);
> }
> +
> + list_for_each_entry(aviommu, &pdom->viommu_list, pdom_list) {
> + struct amd_iommu *iommu;
> +
> + if (!aviommu->trans_dev_data)
> + continue;
> + iommu = container_of(aviommu->core.iommu_dev,
> + struct amd_iommu, iommu);
> + set_dte_entry(iommu, aviommu->trans_dev_data, top_paddr,
> + top_level);
> + }
These two are operating on different page table. So its better to have it in
separate function.
> }
> #else
> static inline void update_viommu_self_dte(struct protection_domain *pdom,
> @@ -3463,6 +3483,95 @@ static bool amd_iommu_enforce_cache_coherency(struct iommu_domain *domain)
> return true;
> }
>
> +#if IS_ENABLED(CONFIG_AMD_IOMMU_IOMMUFD)
why not move this functions to trans_devid.c ?
> +
> +void amd_iommu_update_vfctrl_mmio_translate_devid(struct amd_iommu *iommu,
> + u16 gid, u32 devid)
> +{
> + writeq((devid & 0xFFFFULL) << 16,
> + VIOMMU_VFCTRL_MMIO_BASE(iommu, gid) +
> + VIOMMU_VFCTRL_GUEST_MISC_CONTROL_OFFSET);
> +}
> +
> +int amd_iommu_set_translate_dte(struct iommufd_viommu *viommu)
> +{
> + struct amd_iommu_viommu *aviommu =
> + container_of(viommu, struct amd_iommu_viommu, core);
> + struct amd_iommu *iommu =
> + container_of(viommu->iommu_dev, struct amd_iommu, iommu);
> + struct protection_domain *pdom = aviommu->parent;
> + u16 gid = aviommu->gid;
> + u16 trans_devid = aviommu->trans_devid;
> + struct iommu_dev_data *trans_dev_data;
> + unsigned long flags;
> +
> + if (!aviommu->trans_dev_data) {
> + aviommu->trans_dev_data =
> + amd_iommu_alloc_dev_data(trans_devid);
> + if (!aviommu->trans_dev_data) {
> + pr_err("%s: Failed to allocate dev_data for translate-device-id %#x\n",
> + __func__, trans_devid);
> + return -ENOMEM;
> + }
> + }
> +
> + trans_dev_data = aviommu->trans_dev_data;
> + trans_dev_data->dev = NULL;
> + trans_dev_data->domain = pdom;
> + /*
> + * Leave off pdom->dev_list: this is not an IOMMU-API attach.
> + * Hold pdom->lock so change_top() cannot grow the nest-parent
> + * top between the sample and the DTE commit. Publish devid
> + * under that lock; it is the live TransDevID for
> + * update_viommu_self_dte(). If this vIOMMU is not yet on
> + * viommu_list, add it before dropping the lock so a concurrent
> + * increase_top() cannot miss the new DTE.
> + */
> +
> + spin_lock_irqsave(&pdom->lock, flags);
> + trans_dev_data->devid = trans_devid;
> + set_dte_entry(iommu, trans_dev_data, 0, 0);
> + if (list_empty(&aviommu->pdom_list))
> + list_add(&aviommu->pdom_list, &pdom->viommu_list);
Already updated in amd_iommufd_viommu_init() ?
> + spin_unlock_irqrestore(&pdom->lock, flags);
> +
> + pr_debug("%s: gid=%#x, iommu_devid=%#x, devid=%#x\n",
> + __func__, gid, iommu->devid, trans_devid);
> + return 0;
> +}
> +
> +static void amd_iommu_update_dte_slot(struct amd_iommu *iommu,
> + struct iommu_dev_data *dev_data,
> + u16 devid, struct dev_table_entry *new)
> +{> + update_dte256(iommu, dev_data, devid, new);
> + if (dev_data->dev)
> + clone_aliases(iommu, dev_data->dev);
We know there is no alias device for translation dte right?
Actually why not call amd_iommu_update_dte() . It calls device_flush_dte(), but
for translation dte we are not setting ats_enabled flag.
-Vasant
next prev parent reply other threads:[~2026-10-21 6:16 UTC|newest]
Thread overview: 48+ 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-10-21 5:15 ` Vasant Hegde
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-10-21 5:26 ` Vasant Hegde
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-10-21 5:28 ` Suthikulpanit, Suravee
2026-10-21 5:29 ` Vasant Hegde
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-10-21 6:15 ` Vasant Hegde [this message]
2026-09-30 9:23 ` [PATCH v6 22/24] iommu/amd: Add translate-device-id alloc/free with vIOMMU owner Suravee Suthikulpanit
2026-10-21 6:33 ` Vasant Hegde
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=75e9510f-1dfb-4c59-b2db-48feda7631c1@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®