From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "acpica-devel@lists.linux.dev" <acpica-devel@lists.linux.dev>,
Hanjun Guo <guohanjun@huawei.com>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
Joerg Roedel <joro@8bytes.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Len Brown <lenb@kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Moore, Robert" <robert.moore@intel.com>,
Robin Murphy <robin.murphy@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Will Deacon <will@kernel.org>,
Alex Williamson <alex.williamson@redhat.com>,
Eric Auger <eric.auger@redhat.com>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
Moritz Fischer <mdf@kernel.org>,
Michael Shavit <mshavit@google.com>,
Nicolin Chen <nicolinc@nvidia.com>,
"patches@lists.linux.dev" <patches@lists.linux.dev>,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
Mostafa Saleh <smostafa@google.com>
Subject: Re: [PATCH v2 8/8] iommu/arm-smmu-v3: Support IOMMU_DOMAIN_NESTED
Date: Fri, 30 Aug 2024 11:13:19 -0300 [thread overview]
Message-ID: <20240830141319.GR3773488@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB5276AD532C8F43608A8D30048C972@BN9PR11MB5276.namprd11.prod.outlook.com>
On Fri, Aug 30, 2024 at 08:16:27AM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@nvidia.com>
> > Sent: Tuesday, August 27, 2024 11:52 PM
> >
> > For SMMUv3 a IOMMU_DOMAIN_NESTED is composed of a S2
> > iommu_domain acting
> > as the parent and a user provided STE fragment that defines the CD table
> > and related data with addresses translated by the S2 iommu_domain.
> >
> > The kernel only permits userspace to control certain allowed bits of the
> > STE that are safe for user/guest control.
> >
> > IOTLB maintenance is a bit subtle here, the S1 implicitly includes the S2
> > translation, but there is no way of knowing which S1 entries refer to a
> > range of S2.
> >
> > For the IOTLB we follow ARM's guidance and issue a
> > CMDQ_OP_TLBI_NH_ALL to
> > flush all ASIDs from the VMID after flushing the S2 on any change to the
> > S2.
> >
> > Similarly we have to flush the entire ATC if the S2 is changed.
>
> it's clearer to mention that ATS is not supported at this point.
As things have ended up we need the viommu series to come along with
this to enable the full feature, and viommu supports ATS invalidation.
Ideally I'd like to merge them both together.
> > @@ -2614,7 +2687,8 @@ arm_smmu_find_master_domain(struct
> > arm_smmu_domain *smmu_domain,
> > list_for_each_entry(master_domain, &smmu_domain->devices,
> > devices_elm) {
> > if (master_domain->master == master &&
> > - master_domain->ssid == ssid)
> > + master_domain->ssid == ssid &&
> > + master_domain->nest_parent == nest_parent)
> > return master_domain;
> > }
>
> there are two nest_parent flags in master_domain and smmu_domain.
> Probably duplicating?
Sort of, sort of not..
This is a bit awkward right now because the arm_smmu_domain is still
per-instance, so the domain->nest_parent exists to control flushing of
the VMID
But we also have the per-attachment 'master_domain' struct, and there
the nest_parent controls flushing of the ATC.
In the end arm_smmu_domain will stop being per-instance and per-attach
'master_domain' would have the vmid and the nest_parent only. I'm
aiming for something like how VTD and RISCV are doing their flushing,
with a list of flush instructions attached to the domain.
So for now we have the in-between state where a S2 marked as parent
will avoid the ATC flush when directly attached to a RID but not the
ASID flush. Eventually we will be able to avoid both.
> > +static struct iommu_domain *
> > +arm_smmu_domain_alloc_nesting(struct device *dev, u32 flags,
> > + struct iommu_domain *parent,
> > + const struct iommu_user_data *user_data)
> > +{
> > + struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> > + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> > + struct arm_smmu_nested_domain *nested_domain;
> > + struct arm_smmu_domain *smmu_parent;
> > + struct iommu_hwpt_arm_smmuv3 arg;
> > + unsigned int eats;
> > + unsigned int cfg;
> > + int ret;
> > +
> > + if (!(master->smmu->features & ARM_SMMU_FEAT_NESTING))
> > + return ERR_PTR(-EOPNOTSUPP);
> > +
> > + /*
> > + * Must support some way to prevent the VM from bypassing the
> > cache
> > + * because VFIO currently does not do any cache maintenance.
> > + */
> > + if (!(fwspec->flags & IOMMU_FWSPEC_PCI_RC_CANWBS) &&
> > + !(master->smmu->features & ARM_SMMU_FEAT_S2FWB))
> > + return ERR_PTR(-EOPNOTSUPP);
>
> this can be saved if we guard the setting of NESTING upon them.
IOMMU_FWSPEC_PCI_RC_CANWBS is per-device, FEAT_NESTING is SMMU global,
they can't really be combined.
> > +
> > + ret = iommu_copy_struct_from_user(&arg, user_data,
> > +
> > IOMMU_HWPT_DATA_ARM_SMMUV3, ste);
> > + if (ret)
> > + return ERR_PTR(ret);
>
> prefer to allocating resource after static condition checks below.
>
> > +
> > + if (flags || !(master->smmu->features &
> > ARM_SMMU_FEAT_TRANS_S1))
> > + return ERR_PTR(-EOPNOTSUPP);
>
> Is it possible when NESTING is supported?
>
> > +
> > + if (!(parent->type & __IOMMU_DOMAIN_PAGING))
> > + return ERR_PTR(-EINVAL);
>
> Just check parent->nest_parent
>
> > +
> > + smmu_parent = to_smmu_domain(parent);
> > + if (smmu_parent->stage != ARM_SMMU_DOMAIN_S2 ||
> > + smmu_parent->smmu != master->smmu)
> > + return ERR_PTR(-EINVAL);
>
> again S2 should be implied when parent->nest_parent is true.
I think I did all of these for Nicolin
> > +
> > + /* EIO is reserved for invalid STE data. */
> > + if ((arg.ste[0] & ~STRTAB_STE_0_NESTING_ALLOWED) ||
> > + (arg.ste[1] & ~STRTAB_STE_1_NESTING_ALLOWED))
> > + return ERR_PTR(-EIO);
> > +
> > + cfg = FIELD_GET(STRTAB_STE_0_CFG, le64_to_cpu(arg.ste[0]));
> > + if (cfg != STRTAB_STE_0_CFG_ABORT && cfg !=
> > STRTAB_STE_0_CFG_BYPASS &&
> > + cfg != STRTAB_STE_0_CFG_S1_TRANS)
> > + return ERR_PTR(-EIO);
>
> If vSTE is invalid those bits can be ignored?
Yes, but also I was expecting the VMM to sanitize that.. Let's have
the kernel do it. Move the validation to a function and then:
static int arm_smmu_validate_vste(struct iommu_hwpt_arm_smmuv3 *arg,
unsigned int *eats)
{
unsigned int cfg;
if (!(arg->ste[0] & STRTAB_STE_0_V)) {
memset(arg->ste, 0, sizeof(arg->ste));
return 0;
}
> > +
> > + eats = FIELD_GET(STRTAB_STE_1_EATS, le64_to_cpu(arg.ste[1]));
> > + if (eats != STRTAB_STE_1_EATS_ABT)
> > + return ERR_PTR(-EIO);
> > +
> > + if (cfg != STRTAB_STE_0_CFG_S1_TRANS)
> > + eats = STRTAB_STE_1_EATS_ABT;
>
> this check sounds redundant. If the last check passes then eats is
> already set to _ABT.
Yes.. This hunk needs to go into this patch:
https://lore.kernel.org/linux-iommu/3962bef2ca6ab9bd06a52910f114345ecfe48ba6.1724776335.git.nicolinc@nvidia.com/T/#u
> > +/**
> > + * struct iommu_hwpt_arm_smmuv3 - ARM SMMUv3 Context Descriptor
> > Table info
> > + * (IOMMU_HWPT_DATA_ARM_SMMUV3)
> > + *
> > + * @ste: The first two double words of the user space Stream Table Entry
> > for
> > + * a user stage-1 Context Descriptor Table. Must be little-endian.
> > + * Allowed fields: (Refer to "5.2 Stream Table Entry" in SMMUv3 HW
> > Spec)
> > + * - word-0: V, Cfg, S1Fmt, S1ContextPtr, S1CDMax
> > + * - word-1: S1DSS, S1CIR, S1COR, S1CSH, S1STALLD
>
> Not sure whether EATS should be documented here or not. It's handled
> but must be ZERO at this point.
Let's put it in the above patch
Thanks,
Jason
next prev parent reply other threads:[~2024-08-30 14:19 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-27 15:51 [PATCH v2 0/8] Initial support for SMMUv3 nested translation Jason Gunthorpe
2024-08-27 15:51 ` [PATCH v2 1/8] vfio: Remove VFIO_TYPE1_NESTING_IOMMU Jason Gunthorpe
2024-08-30 7:40 ` Tian, Kevin
2024-08-27 15:51 ` [PATCH v2 2/8] iommu/arm-smmu-v3: Use S2FWB when available Jason Gunthorpe
2024-08-27 19:48 ` Nicolin Chen
2024-08-28 18:30 ` Jason Gunthorpe
2024-08-28 19:47 ` Nicolin Chen
2024-08-28 19:50 ` Nicolin Chen
2024-08-30 7:44 ` Tian, Kevin
2024-08-30 7:56 ` Nicolin Chen
2024-08-30 8:01 ` Tian, Kevin
2024-08-30 15:12 ` Mostafa Saleh
2024-08-30 16:40 ` Jason Gunthorpe
2024-09-02 9:29 ` Mostafa Saleh
2024-09-03 0:05 ` Jason Gunthorpe
2024-09-03 7:57 ` Mostafa Saleh
2024-09-03 23:33 ` Jason Gunthorpe
2024-09-10 10:55 ` Mostafa Saleh
2024-09-10 20:22 ` Jason Gunthorpe
2024-09-17 9:48 ` Mostafa Saleh
2024-09-04 14:20 ` Shameerali Kolothum Thodi
2024-09-04 15:00 ` Jason Gunthorpe
2024-09-10 11:25 ` Shameerali Kolothum Thodi
2024-09-11 22:52 ` Jason Gunthorpe
2024-08-27 15:51 ` [PATCH v2 3/8] ACPICA: IORT: Update for revision E.f Jason Gunthorpe
2024-08-29 10:14 ` Rafael J. Wysocki
2024-08-27 15:51 ` [PATCH v2 4/8] ACPI/IORT: Support CANWBS memory access flag Jason Gunthorpe
2024-08-30 7:52 ` Tian, Kevin
2024-08-30 13:54 ` Jason Gunthorpe
2024-09-03 7:14 ` Tian, Kevin
2024-08-27 15:51 ` [PATCH v2 5/8] iommu/arm-smmu-v3: Report IOMMU_CAP_ENFORCE_CACHE_COHERENCY for CANWBS Jason Gunthorpe
2024-08-27 20:12 ` Nicolin Chen
2024-08-28 19:12 ` Jason Gunthorpe
2024-08-30 15:19 ` Mostafa Saleh
2024-08-30 17:10 ` Jason Gunthorpe
2024-08-27 15:51 ` [PATCH v2 6/8] iommu/arm-smmu-v3: Support IOMMU_GET_HW_INFO via struct arm_smmu_hw_info Jason Gunthorpe
2024-08-30 7:55 ` Tian, Kevin
2024-08-30 15:23 ` Mostafa Saleh
2024-08-30 17:16 ` Jason Gunthorpe
2024-09-02 10:11 ` Mostafa Saleh
2024-09-03 0:16 ` Jason Gunthorpe
2024-09-03 8:34 ` Mostafa Saleh
2024-09-03 23:40 ` Jason Gunthorpe
2024-09-04 7:11 ` Shameerali Kolothum Thodi
2024-09-04 12:01 ` Jason Gunthorpe
2024-09-06 11:19 ` Mostafa Saleh
2024-08-27 15:51 ` [PATCH v2 7/8] iommu/arm-smmu-v3: Implement IOMMU_HWPT_ALLOC_NEST_PARENT Jason Gunthorpe
2024-08-27 20:16 ` Nicolin Chen
2024-08-30 7:58 ` Tian, Kevin
2024-08-30 13:55 ` Jason Gunthorpe
2024-08-30 15:27 ` Mostafa Saleh
2024-08-30 17:18 ` Jason Gunthorpe
2024-09-02 8:57 ` Mostafa Saleh
2024-08-27 15:51 ` [PATCH v2 8/8] iommu/arm-smmu-v3: Support IOMMU_DOMAIN_NESTED Jason Gunthorpe
2024-08-27 21:23 ` Nicolin Chen
2024-08-28 19:01 ` Jason Gunthorpe
2024-08-28 19:27 ` Nicolin Chen
2024-08-30 8:16 ` Tian, Kevin
2024-08-30 14:13 ` Jason Gunthorpe [this message]
2024-08-30 14:39 ` Jason Gunthorpe
2024-08-30 16:09 ` Mostafa Saleh
2024-08-30 16:59 ` Nicolin Chen
2024-08-30 17:04 ` Jason Gunthorpe
2024-09-02 9:57 ` Mostafa Saleh
2024-09-03 0:30 ` Jason Gunthorpe
2024-09-03 1:13 ` Nicolin Chen
2024-09-03 9:00 ` Mostafa Saleh
2024-09-03 23:55 ` Jason Gunthorpe
2024-09-06 11:07 ` Mostafa Saleh
2024-09-06 13:34 ` Jason Gunthorpe
2024-09-10 11:12 ` Mostafa Saleh
2024-09-15 21:39 ` Jason Gunthorpe
2024-09-06 18:28 ` Jason Gunthorpe
2024-09-06 18:49 ` Nicolin Chen
2024-09-06 23:15 ` Jason Gunthorpe
2024-08-27 21:31 ` [PATCH v2 0/8] Initial support for SMMUv3 nested translation Nicolin Chen
2024-08-28 16:31 ` Shameerali Kolothum Thodi
2024-08-28 17:14 ` Nicolin Chen
2024-08-28 18:06 ` Shameerali Kolothum Thodi
2024-08-28 18:12 ` Nicolin Chen
2024-08-29 13:14 ` Shameerali Kolothum Thodi
2024-08-29 14:52 ` Shameerali Kolothum Thodi
2024-08-29 16:10 ` Nicolin Chen
2024-08-30 9:07 ` Shameerali Kolothum Thodi
2024-08-30 17:01 ` Nicolin Chen
2024-09-12 3:42 ` Zhangfei Gao
2024-09-12 4:05 ` Nicolin Chen
2024-09-12 4:25 ` Baolu Lu
2024-09-12 7:32 ` Zhangfei Gao
2024-10-15 3:21 ` Zhangfei Gao
2024-10-15 13:09 ` Jason Gunthorpe
2024-10-17 1:53 ` Zhangfei Gao
2024-10-17 11:57 ` Jason Gunthorpe
2024-10-16 2:23 ` Zhangfei Gao
2024-10-16 11:53 ` Jason Gunthorpe
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=20240830141319.GR3773488@nvidia.com \
--to=jgg@nvidia.com \
--cc=acpica-devel@lists.linux.dev \
--cc=alex.williamson@redhat.com \
--cc=eric.auger@redhat.com \
--cc=guohanjun@huawei.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=mdf@kernel.org \
--cc=mshavit@google.com \
--cc=nicolinc@nvidia.com \
--cc=patches@lists.linux.dev \
--cc=rafael@kernel.org \
--cc=robert.moore@intel.com \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=smostafa@google.com \
--cc=sudeep.holla@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;
as well as URLs for NNTP newsgroup(s).