From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: "kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Linuxarm <linuxarm@huawei.com>,
"kevin.tian@intel.com" <kevin.tian@intel.com>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"maz@kernel.org" <maz@kernel.org>,
"oliver.upton@linux.dev" <oliver.upton@linux.dev>,
"will@kernel.org" <will@kernel.org>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"nicolinc@nvidia.com" <nicolinc@nvidia.com>,
"jean-philippe@linaro.org" <jean-philippe@linaro.org>,
Jonathan Cameron <jonathan.cameron@huawei.com>
Subject: RE: [RFC PATCH v3 4/5] iommu/arm-smmu-v3-iommufd: Use KVM VMID for s2 stage
Date: Thu, 20 Mar 2025 09:30:45 +0000 [thread overview]
Message-ID: <f654ae10e55e4142acb83eb926bb80b2@huawei.com> (raw)
In-Reply-To: <20250319233946.GF126678@ziepe.ca>
> -----Original Message-----
> From: Jason Gunthorpe <jgg@ziepe.ca>
> Sent: Wednesday, March 19, 2025 11:40 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: kvmarm@lists.linux.dev; iommu@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; Linuxarm <linuxarm@huawei.com>;
> kevin.tian@intel.com; alex.williamson@redhat.com; maz@kernel.org;
> oliver.upton@linux.dev; will@kernel.org; robin.murphy@arm.com;
> nicolinc@nvidia.com; jean-philippe@linaro.org; Jonathan Cameron
> <jonathan.cameron@huawei.com>
> Subject: Re: [RFC PATCH v3 4/5] iommu/arm-smmu-v3-iommufd: Use KVM
> VMID for s2 stage
>
> On Wed, Mar 19, 2025 at 05:32:01PM +0000, Shameer Kolothum wrote:
> > +static int arm_vsmmu_alloc_vmid(struct arm_smmu_device *smmu,
> struct kvm *kvm,
> > + bool *kvm_used)
> > +{
> > +#ifdef CONFIG_KVM
> > + /*
> > + * There can only be one allocator for VMIDs active at once. If BTM
> is
> > + * turned on then KVM's allocator always supplies the VMID, and
> the
> > + * VMID is matched by CPU invalidation of the KVM S2. Right now
> there
> > + * is no API to get an unused VMID from KVM so this also means
> BTM systems
> > + * cannot support S2 without an associated KVM.
> > + */
> > + if ((smmu->features & ARM_SMMU_FEAT_BTM)) {
> > + int vmid;
> > +
> > + if (!kvm || !kvm_get_kvm_safe(kvm))
> > + return -EOPNOTSUPP;
>
> Isn't kvm_get_kvm_safe() in modular KVM code most of the time? You can't
> call it like this right?
I think it is safe since KVM is not modular for ARM64. And that is one of the
reasons I thought I will hold the KVM reference here as we don't have to go
through the symbol_get/put calls here. Also IOMMUFD is not using the kvm
pointer at the moment. Probably I should add some comments in IOMMUFD
to make it clear.
However I just realized that in patch #1 I should EXPORT the
kvm_arm_pinned_vmid_get/put functions as smmuv3 driver can be built
modular.
>
> Per my prior comments, I'm a little nervous to make drivers keep track
> of this refcount instead of the core code but this does seem like it
> could work..
>
> I also think you should block using the S2 without a viommu & KVM in
> BTM mode.. Maybe like this:
>
> @@ -2938,8 +2938,16 @@ static int arm_smmu_attach_dev(struct
> iommu_domain *domain, struct device *dev)
> cdptr = arm_smmu_alloc_cd_ptr(master, IOMMU_NO_PASID);
> if (!cdptr)
> return -ENOMEM;
> - } else if (arm_smmu_ssids_in_use(&master->cd_table))
> - return -EBUSY;
> + } else {
> + if (arm_smmu_ssids_in_use(&master->cd_table))
> + return -EBUSY;
> + /*
> + * S2 cannot be used when BTM is turned on without a VIOMMU
> and
> + * VMID shared with KVM
> + */
> + if (smmu->features & ARM_SMMU_FEAT_BTM)
> + return -EOPNOTSUPP;
> + }
>
> That more closely matches how this will eventually work when the VMID
> allocation is properly made to be local to the viommu.
Ok. Will update.
Thanks,
Shameer
next prev parent reply other threads:[~2025-03-20 9:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-19 17:31 [RFC PATCH v3 0/5] iommu/arm-smmu-v3: Use pinned KVM VMID for stage 2 Shameer Kolothum
2025-03-19 17:31 ` [RFC PATCH v3 1/5] KVM: arm64: Introduce support to pin VMIDs Shameer Kolothum
2025-03-19 17:31 ` [RFC PATCH v3 2/5] iommufd/device: Associate a kvm pointer to iommufd_device Shameer Kolothum
2025-03-19 23:28 ` Jason Gunthorpe
2025-03-19 17:32 ` [RFC PATCH v3 3/5] iommu/arm-smmu-v3-iommufd: Pass in kvm pointer to viommu_alloc Shameer Kolothum
2025-03-19 23:31 ` Jason Gunthorpe
2025-03-19 17:32 ` [RFC PATCH v3 4/5] iommu/arm-smmu-v3-iommufd: Use KVM VMID for s2 stage Shameer Kolothum
2025-03-19 23:39 ` Jason Gunthorpe
2025-03-20 9:30 ` Shameerali Kolothum Thodi [this message]
2025-03-20 12:27 ` Jason Gunthorpe
2025-03-19 17:32 ` [RFC PATCH v3 5/5] iommu/arm-smmu-v3: Enable broadcast TLB maintenance Shameer Kolothum
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=f654ae10e55e4142acb83eb926bb80b2@huawei.com \
--to=shameerali.kolothum.thodi@huawei.com \
--cc=alex.williamson@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=jgg@ziepe.ca \
--cc=jonathan.cameron@huawei.com \
--cc=kevin.tian@intel.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linuxarm@huawei.com \
--cc=maz@kernel.org \
--cc=nicolinc@nvidia.com \
--cc=oliver.upton@linux.dev \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
/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