[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aQu-Jy27_PzxqVvt@google.com>
Date: Wed, 5 Nov 2025 21:14:15 +0000
From: Pranjal Shrivastava <praan@...gle.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: jgg@...dia.com, will@...nel.org, robin.murphy@....com, joro@...tes.org,
kevin.tian@...el.com, linux-arm-kernel@...ts.infradead.org,
iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
skolothumtho@...dia.com
Subject: Re: [PATCH v2] iommu/arm-smmu-v3-iommufd: Allow attaching nested
domain for GBPA cases
On Mon, Nov 03, 2025 at 09:27:55AM -0800, Nicolin Chen wrote:
> A vDEVICE has been a hard requirement for attaching a nested domain to the
> device. This makes sense when installing a guest STE, since a vSID must be
> present and given to the kernel during the vDEVICE allocation.
>
> But, when CR0.SMMUEN is disabled, VM doesn't really need a vSID to program
> the vSMMU behavior as GBPA will take effect, in which case the vSTE in the
> nested domain could have carried the bypass or abort configuration in GBPA
> register. Thus, having such a hard requirement doesn't work well for GBPA.
>
> Skip vmaster allocation in arm_smmu_attach_prepare_vmaster() for an abort
> or bypass vSTE. Note that device on this attachment won't report vevents.
>
> Update the uAPI doc accordingly.
>
> Tested-by: Shameer Kolothum <skolothumtho@...dia.com>
> Signed-off-by: Nicolin Chen <nicolinc@...dia.com>
> ---
>
> Changelog
> v2
> * Add Tested-by from Shameer
> * Skip vmaster allocation instead of bypassing vsid=0
> * Revise the uAPI doc to note a corner case when CR0.SMMUEN=1
>
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 13 ++++++++++++-
> include/uapi/linux/iommufd.h | 9 +++++++++
> 2 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
> index 8cd8929bbfdf8..e5fbbdbdea242 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
> @@ -99,6 +99,8 @@ static void arm_smmu_make_nested_domain_ste(
> int arm_smmu_attach_prepare_vmaster(struct arm_smmu_attach_state *state,
> struct arm_smmu_nested_domain *nested_domain)
> {
> + unsigned int cfg =
> + FIELD_GET(STRTAB_STE_0_CFG, le64_to_cpu(nested_domain->ste[0]));
> struct arm_smmu_vmaster *vmaster;
> unsigned long vsid;
> int ret;
> @@ -107,8 +109,17 @@ int arm_smmu_attach_prepare_vmaster(struct arm_smmu_attach_state *state,
>
> ret = iommufd_viommu_get_vdev_id(&nested_domain->vsmmu->core,
> state->master->dev, &vsid);
> - if (ret)
> + /*
> + * Attaching to a translate nested domain must allocate a vDEVICE prior,
> + * as CD/ATS invalidations and vevents require a vSID to work properly.
> + * A abort/bypass domain is allowed to attach w/o vmaster for GBPA case.
> + */
> + if (ret) {
> + if (cfg == STRTAB_STE_0_CFG_ABORT ||
> + cfg == STRTAB_STE_0_CFG_BYPASS)
> + return 0;
> return ret;
> + }
>
Skipping the vmaster allocation entirely for the GBPA-only case (when no
vdevice is found) is much cleaner. Thanks!
> vmaster = kzalloc(sizeof(*vmaster), GFP_KERNEL);
> if (!vmaster)
> diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
> index c218c89e0e2eb..225671603ade6 100644
> --- a/include/uapi/linux/iommufd.h
> +++ b/include/uapi/linux/iommufd.h
> @@ -450,6 +450,15 @@ struct iommu_hwpt_vtd_s1 {
> * nested domain will translate the same as the nesting parent. The S1 will
> * install a Context Descriptor Table pointing at userspace memory translated
> * by the nesting parent.
> + *
> + * It's suggested to allocate a vDEVICE object carrying vSID and then re-attach
> + * the nested domain, as soon as the vSID is available in the VMM level:
> + * - when Cfg=translate, a vDEVICE must be allocated prior to attaching to the
> + * allocated nested domain, as CD/ATS invalidations and vevents need a vSID.
> + * - when Cfg=bypass/abort, a vDEVICE is not enforced during the nested domain
> + * attachment, to support a GBPA case where VM sets CR0.SMMUEN=0. However, if
> + * VM sets CR0.SMMUEN=1 while missing a vDEVICE object, kernel would fail to
> + * report events to the VM. E.g. F_TRANSLATION when guest STE.Cfg=abort.
> */
Reviewed-by: Pranjal Shrivastava <praan@...gle.com>
Thanks,
Praan
Powered by blists - more mailing lists