All of lore.kernel.org
 help / color / mirror / Atom feed
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 16/24] iommu/amd: Add IOMMUFD vDevice and DevID mapping
Date: Wed, 21 Oct 2026 10:45:10 +0530	[thread overview]
Message-ID: <93e123d5-e97d-4377-93f1-06322742b10f@amd.com> (raw)
In-Reply-To: <20260930092344.5616-17-suravee.suthikulpanit@amd.com>



On 9/30/2026 2:53 PM, Suravee Suthikulpanit wrote:
> IOMMUFD vDevice allocation supplies the guest device ID (virt_id).
> The AMD vIOMMU Device ID mapping table translates that gdev_id to the
> host device ID for virtualised IOMMU commands.
> 
> Add vdevice_init, which validates a PCI device and virt_id, then
> programs the mapping through VFCTRL via amd_viommu_set_device_mapping().
> Get the host struct device via iommufd_vdevice_to_device(). Set
> vdev->destroy to restore an idle mapping when the vDevice is removed
> while the vIOMMU is still alive.
> 
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> ---
>  drivers/iommu/amd/amd_iommu_types.h | 12 +++++
>  drivers/iommu/amd/amd_viommu.h      | 10 ++++
>  drivers/iommu/amd/iommufd.c         | 52 +++++++++++++++++++
>  drivers/iommu/amd/viommu.c          | 79 ++++++++++++++++++++++++++++-
>  4 files changed, 152 insertions(+), 1 deletion(-)
> 


.../...

> +}
> +
> +/*
> + * Called from drivers/iommu/iommufd/viommu.c: iommufd_vdevice_abort()
> + *
> + * Restore an idle DevID map entry for this virt_id. Every DevID mapping
> + * table slot must have V=1 for both active and non-active devices. A
> + * non-valid entry raises INVALID_DEVICE_REQUEST when the IOMMU processes
> + * INVALIDATE_IOMMU_ALL. Use host device ID 0: that RID is the IOMMU PCI

We don't support  INVALIDATE_IOMMU_ALL command inside guest. But with current
kernel guest will endup walking entire devid/dom Id range and hitting
INVALID_DEVICE_REQUEST.

> + * function and does not normally host an endpoint.
> + */
> +static void _amd_viommu_vdevice_destroy(struct iommufd_vdevice *vdev)
> +{
> +	struct iommufd_viommu *viommu = vdev->viommu;
> +	struct amd_iommu_viommu *aviommu =
> +		container_of(viommu, struct amd_iommu_viommu, core);
> +
> +	amd_viommu_set_device_mapping(aviommu, 0, (u16)vdev->virt_id);
> +}
> +
> +/*
> + * Called from drivers/iommu/iommufd/viommu.c: iommufd_vdevice_alloc_ioctl()
> + */
> +static int _amd_viommu_vdevice_init(struct iommufd_vdevice *vdev)
> +{
> +	struct device *dev = iommufd_vdevice_to_device(vdev);
> +	struct pci_dev *pdev;
> +	struct iommufd_viommu *viommu = vdev->viommu;
> +	struct amd_iommu_viommu *aviommu = container_of(viommu, struct amd_iommu_viommu, core);
> +
> +	if (!dev_is_pci(dev))
> +		return -EINVAL;
> +	pdev = to_pci_dev(dev);
> +
> +	if (vdev->virt_id > VIOMMU_MAX_GDEVID) {
> +		pr_err("%s: Invalid virtual ID (virt_id=%#llx)\n", __func__, vdev->virt_id);
> +		return -EINVAL;
> +	}
> +
> +	pr_debug("%s: gid=%#x, hdev_id=%#x, gdev_id=%#llx\n", __func__,
> +		 aviommu->gid, pci_dev_id(pdev), vdev->virt_id);
> +
> +	amd_viommu_set_device_mapping(aviommu, pci_dev_id(pdev),
> +				      (u16)vdev->virt_id);
> +	vdev->destroy = _amd_viommu_vdevice_destroy;
> +
> +	return 0;
>  }
>  
>  /*
> @@ -149,4 +199,6 @@ static void amd_iommufd_viommu_destroy(struct iommufd_viommu *viommu)
>  static const struct iommufd_viommu_ops amd_viommu_ops = {
>  	.alloc_domain_nested = amd_iommu_alloc_domain_nested,
>  	.destroy = amd_iommufd_viommu_destroy,
> +	.vdevice_size = VDEVICE_STRUCT_SIZE(struct amd_iommu_vdevice, core),
> +	.vdevice_init = _amd_viommu_vdevice_init,
>  };
> diff --git a/drivers/iommu/amd/viommu.c b/drivers/iommu/amd/viommu.c
> index b160c70f3804..e263d63afe3d 100644
> --- a/drivers/iommu/amd/viommu.c
> +++ b/drivers/iommu/amd/viommu.c
> @@ -6,6 +6,7 @@
>  #define pr_fmt(fmt)     "AMD-Vi: " fmt
>  #define dev_fmt(fmt)    pr_fmt(fmt)
>  
> +#include <linux/delay.h>
>  #include <linux/iommu.h>
>  #include <linux/iommufd.h>
>  #include <uapi/linux/iommufd.h>
> @@ -29,7 +30,6 @@
>   * VIOMMU_MAX_GDEVID / VIOMMU_MAX_GDOMID are 16-bit guest DevID
>   * and DomID table indices (hardware mapping-table width), not GID.
>   */
> -#define VIOMMU_MAX_GDEVID		0xFFFF
>  #define VIOMMU_DEVID_MAPPING_BASE	0x1000000000ULL
>  #define VIOMMU_DEVID_MAPPING_ENTRY_SIZE	(1 << 20)
>  
> @@ -45,6 +45,8 @@ static_assert(VIOMMU_DEVID_MAPPING_ENTRY_SIZE >=
>  static_assert(VIOMMU_DOMID_MAPPING_ENTRY_SIZE >=
>  	      (VIOMMU_MAX_GDOMID + 1ULL) * sizeof(u64));
>  
> +#define VIOMMU_VFCTRL_GUEST_DID_MAP_CONTROL0_OFFSET	0x00
> +
>  static void __init amd_viommu_vf_vfcntl_unmap(struct amd_iommu *iommu)
>  {
>  	if (iommu->vfctrl_base) {
> @@ -448,6 +450,81 @@ static void __maybe_unused free_private_vm_region(struct amd_iommu *iommu, u64 *
>  	*entry = NULL;
>  }
>  
> +#define DEVID_ENTRY_GDEVID_MASK		GENMASK_ULL(61, 46)
> +#define DEVID_ENTRY_QUEUEID_MASK	GENMASK_ULL(45, 30)
> +#define DEVID_ENTRY_HDEVID_MASK		GENMASK_ULL(29, 14)
> +#define DEVID_ENTRY_WRITE		BIT_ULL(63)
> +#define DEVID_ENTRY_VALID		BIT_ULL(0)
> +
> +/*
> + * CONTROL0/CONTROL1 bit 63 (WRITE) is a doorbell: hardware copies one
> + * entry into the IPA-backed table and clears WRITE when that DMA write
> + * retires. This is not a command-buffer operation;
> + * iommu_completion_wait() does not drain it. A readq() of CONTROL_EN
> + * is also unrelated. Poll WRITE=0 before ringing a new doorbell and
> + * after each write so the table update is retired before the caller
> + * proceeds (DTE commit, unmap/free).
> + */
> +static void vfctrl_wait_write_clear(struct amd_iommu *iommu, u16 gid,
> +				    unsigned int offset)
> +{
> +	u8 __iomem *reg = VIOMMU_VFCTRL_MMIO_BASE(iommu, gid) + offset;
> +	int i;
> +
> +	for (i = 0; i < LOOP_TIMEOUT; i++) {
> +		if (!(readq(reg) & DEVID_ENTRY_WRITE))
> +			return;
> +		udelay(1);
> +	}
> +	pr_err("%s: WRITE timeout gid=%#x offset=%#x val=%#llx\n",
> +	       __func__, gid, offset, readq(reg));

Shouldn't -ETIMEDOUT propagate so that vDevice allocation fails when
the mapping was never committed?


> +}
> +
> +/*
> + * Guest DevID table update via VFCTRL CONTROL0.
> + *
> + * TODO: The driver does not support QueueID yet,
> + *       so current callers pass 0. This will be
> + *       enhanced in the future.
> + */
> +static void set_device_mapping_unlocked(struct amd_iommu *iommu, u16 gid,

You mean mapping_locked?

-Vasant


  parent reply	other threads:[~2026-10-21  5:15 UTC|newest]

Thread overview: 50+ 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 [this message]
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
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-10-21 10:06   ` Vasant Hegde
2026-09-30  9:23 ` [PATCH v6 24/24] iommu/amd: Relocate vIOMMU translate-device-id on PCI reserve Suravee Suthikulpanit
2026-10-21 10:09   ` Vasant Hegde
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=93e123d5-e97d-4377-93f1-06322742b10f@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.