Re: [PATCH v6 18/24] iommu/amd: Init and clear vIOMMU DevID and DomID maps

[Vasant Hegde <vasant.hegde@amd.com>]

On 9/30/2026 2:53 PM, Suravee Suthikulpanit 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.
> 
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> ---
>  drivers/iommu/amd/viommu.c | 90 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 90 insertions(+)
> 
> diff --git a/drivers/iommu/amd/viommu.c b/drivers/iommu/amd/viommu.c
> index e2275d6b7442..2f299a16d113 100644
> --- a/drivers/iommu/amd/viommu.c
> +++ b/drivers/iommu/amd/viommu.c
> @@ -7,6 +7,7 @@
>  #define dev_fmt(fmt)    pr_fmt(fmt)
>  


.../...

> +
> +/*
> + * Prefill every guest ID so hardware never sees an unknown mapping.
> + * Map all gdom_id to the nest parent domain ID, and all gdev_id with
> + * hdev_id 0 and QueueID 0. Cannot be scoped to IDs in use: none exist
> + * yet, and INVALIDATE_IOMMU_ALL walks the HW table.

We don't support INVALIDATE_IOMMU_ALL inside guest.

> + *
> + * Drop vfctrl_lock every VIOMMU_VFCTRL_PREFILL_RESCHED doorbells so
> + * the 128K MMIO loop can yield. Safe on init: vDevice/nested attach
> + * cannot run until viommu->ops is published after init_one().
> + */
> +static void viommu_prefill_mapping(struct amd_iommu *iommu,
> +				   struct amd_iommu_viommu *aviommu)
> +{
> +	int i;
> +	u16 gid = aviommu->gid;
> +
> +	if (!viommu_vfctrl_ready(iommu))

Why? We will not hit this path if vfctl_base is not setup or command buffer is
not enabled.

> +		return;
> +
> +	mutex_lock(&aviommu->vfctrl_lock);

May be without lock as no one  else will call this until viommu_init is completed?

-Vasant