From: Shameerali Kolothum Thodi via <qemu-devel@nongnu.org>
To: Nicolin Chen <nicolinc@nvidia.com>, Donald Dutile <ddutile@redhat.com>
Cc: Zhenzhong Duan <zhenzhong.duan@intel.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"clg@redhat.com" <clg@redhat.com>,
"eric.auger@redhat.com" <eric.auger@redhat.com>,
"mst@redhat.com" <mst@redhat.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
"peterx@redhat.com" <peterx@redhat.com>,
"jgg@nvidia.com" <jgg@nvidia.com>,
"joao.m.martins@oracle.com" <joao.m.martins@oracle.com>,
"clement.mathieu--drif@eviden.com"
<clement.mathieu--drif@eviden.com>,
"kevin.tian@intel.com" <kevin.tian@intel.com>,
"yi.l.liu@intel.com" <yi.l.liu@intel.com>,
"chao.p.peng@intel.com" <chao.p.peng@intel.com>
Subject: RE: [PATCH v3 02/20] hw/pci: Introduce pci_device_get_viommu_cap()
Date: Thu, 10 Jul 2025 08:11:28 +0000 [thread overview]
Message-ID: <b3787ed4219743e2a65edd13ff44d9b9@huawei.com> (raw)
In-Reply-To: <aG7A8hxd1R4iVhGT@Asurada-Nvidia>
> -----Original Message-----
> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Wednesday, July 9, 2025 8:20 PM
> To: Donald Dutile <ddutile@redhat.com>
> Cc: Zhenzhong Duan <zhenzhong.duan@intel.com>; qemu-
> devel@nongnu.org; alex.williamson@redhat.com; clg@redhat.com;
> eric.auger@redhat.com; mst@redhat.com; jasowang@redhat.com;
> peterx@redhat.com; jgg@nvidia.com; Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>; joao.m.martins@oracle.com;
> clement.mathieu--drif@eviden.com; kevin.tian@intel.com;
> yi.l.liu@intel.com; chao.p.peng@intel.com
> Subject: Re: [PATCH v3 02/20] hw/pci: Introduce
> pci_device_get_viommu_cap()
>
> On Wed, Jul 09, 2025 at 01:55:46PM -0400, Donald Dutile wrote:
> > > > +enum {
> > > > + VIOMMU_CAP_STAGE1 = BIT_ULL(0), /* stage1 page table
> supported */
> > > > +};
> > >
> > > Thanks for this work. I am happy to see that we can share the
> > > common code that allocates a NESTING_PARENT in the core using
> > > this flag.
> > >
> > > Yet on ARM, a STAGE1 page table isn't always a nested S1, the
> > > hardware accelerated one. More often, it can be just a regular
> > > 1-stage translation table via emulated translation code and an
> > > emulated iotlb.
> > >
> > Because the user-created smmuv3 started as 'accelerated smmuv3',
> > and had been 'de-accelerated' to simply 'user created smmuv3',
> > I'm looking for some clarification in the above statement/request.
> >
> > Is the above suppose to reflect that a nested IOMMU has some hw-
> acceleration
> > in its Stage1 implementation?
> > If so, then call it that: STAGE1_ACCEL.
> > If it's suppose to represent that an IOMMU has nested/2-stage support,
> > then the above is a valid cap; -but-, having a nested/2-stage support
> IOMMU
> > doesn't necessarily mean its accelerated.
>
> Well, there are an emulated "nested" mode and an hw-accelerated
> "nested" mode in the smmuv3 code, so we had to choose something
> like "accel" over "nested".
>
> Here, on the other hand, I think the core using this CAP would
> unlikely care about an emulated "nested" mode in the individual
> vIOMMU..
>
> So I suggested:
> /* hardware-accelerated nested stage-1 page table support */
> VIOMMU_CAP_NESTED_S1 = BIT_ULL(0),
>
> which it should be clear IMHO.
>
> If not, maybe go a bit further like "VIOMMU_CAP_HW_NESTED_S1"?
I am not sure the _S1 part makes much sense in ARM case. It doesn't matter
whether the Guest SMMUv3 is configured in s1/s2 or nested for this CAP.
With the new SMMUv3 dev support, the user can pretty much specify,
-device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.1,accel=on,stage={stage1|stage2|nested}
And I think it will work with a host SMMUv3 nested configuration in all the
above cases. Unless I am missing something and we need to restrict its
use with stage=stage1 only.
Thanks,
Shameer
next prev parent reply other threads:[~2025-07-10 8:12 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-08 11:05 [PATCH v3 00/20] intel_iommu: Enable stage-1 translation for passthrough device Zhenzhong Duan
2025-07-08 11:05 ` [PATCH v3 01/20] intel_iommu: Rename vtd_ce_get_rid2pasid_entry to vtd_ce_get_pasid_entry Zhenzhong Duan
2025-07-08 11:05 ` [PATCH v3 02/20] hw/pci: Introduce pci_device_get_viommu_cap() Zhenzhong Duan
2025-07-09 0:39 ` Nicolin Chen
2025-07-09 3:38 ` Duan, Zhenzhong
2025-07-09 4:03 ` Nicolin Chen
2025-07-09 5:52 ` Duan, Zhenzhong
2025-07-09 17:55 ` Donald Dutile
2025-07-09 19:20 ` Nicolin Chen
2025-07-10 1:22 ` Donald Dutile
2025-07-15 15:28 ` Eric Auger
2025-07-15 16:42 ` Donald Dutile
2025-07-10 8:11 ` Shameerali Kolothum Thodi via [this message]
2025-07-10 17:01 ` Donald Dutile
2025-07-10 17:07 ` Donald Dutile
2025-07-10 17:25 ` Nicolin Chen
2025-07-10 17:16 ` Nicolin Chen
2025-07-11 13:18 ` Shameerali Kolothum Thodi via
2025-07-15 15:36 ` Eric Auger
2025-07-08 11:05 ` [PATCH v3 03/20] intel_iommu: Implement get_viommu_cap() callback Zhenzhong Duan
2025-07-15 16:32 ` Eric Auger
2025-07-08 11:05 ` [PATCH v3 04/20] vfio/iommufd: Force creating nested parent domain Zhenzhong Duan
2025-07-15 16:36 ` Eric Auger
2025-07-08 11:05 ` [PATCH v3 05/20] hw/pci: Export pci_device_get_iommu_bus_devfn() and return bool Zhenzhong Duan
2025-07-15 16:40 ` Eric Auger
2025-07-16 3:29 ` Duan, Zhenzhong
2025-07-08 11:05 ` [PATCH v3 06/20] intel_iommu: Introduce a new structure VTDHostIOMMUDevice Zhenzhong Duan
2025-07-08 11:05 ` [PATCH v3 07/20] intel_iommu: Check for compatibility with IOMMUFD backed device when x-flts=on Zhenzhong Duan
2025-07-16 9:22 ` Eric Auger
2025-07-16 10:31 ` Duan, Zhenzhong
2025-07-16 12:09 ` Eric Auger
2025-07-17 3:47 ` Duan, Zhenzhong
2025-07-17 6:48 ` Eric Auger
2025-07-17 7:03 ` Duan, Zhenzhong
2025-07-08 11:05 ` [PATCH v3 08/20] intel_iommu: Fail passthrough device under PCI bridge if x-flts=on Zhenzhong Duan
2025-07-16 9:53 ` Eric Auger
2025-07-17 3:24 ` Duan, Zhenzhong
2025-07-08 11:05 ` [PATCH v3 09/20] intel_iommu: Introduce two helpers vtd_as_from/to_iommu_pasid_locked Zhenzhong Duan
2025-07-16 12:53 ` Eric Auger
2025-07-17 3:48 ` Duan, Zhenzhong
2025-07-08 11:05 ` [PATCH v3 10/20] intel_iommu: Handle PASID entry removing and updating Zhenzhong Duan
2025-07-16 15:10 ` Eric Auger
2025-07-17 7:02 ` Duan, Zhenzhong
2025-07-08 11:05 ` [PATCH v3 11/20] intel_iommu: Handle PASID entry adding Zhenzhong Duan
2025-07-16 16:44 ` Eric Auger
2025-07-17 7:15 ` Duan, Zhenzhong
2025-07-08 11:05 ` [PATCH v3 12/20] intel_iommu: Introduce a new pasid cache invalidation type FORCE_RESET Zhenzhong Duan
2025-07-08 11:05 ` [PATCH v3 13/20] intel_iommu: Stick to system MR for IOMMUFD backed host device when x-fls=on Zhenzhong Duan
2025-07-08 11:05 ` [PATCH v3 14/20] intel_iommu: Bind/unbind guest page table to host Zhenzhong Duan
2025-07-08 11:05 ` [PATCH v3 15/20] intel_iommu: Replay pasid bindings after context cache invalidation Zhenzhong Duan
2025-07-08 11:05 ` [PATCH v3 16/20] intel_iommu: Propagate PASID-based iotlb invalidation to host Zhenzhong Duan
2025-07-08 11:05 ` [PATCH v3 17/20] intel_iommu: Replay all pasid bindings when either SRTP or TE bit is changed Zhenzhong Duan
2025-07-08 11:05 ` [PATCH v3 18/20] vfio: Add a new element bypass_ro in VFIOContainerBase Zhenzhong Duan
2025-07-08 11:06 ` [PATCH v3 19/20] Workaround for ERRATA_772415_SPR17 Zhenzhong Duan
2025-07-08 11:06 ` [PATCH v3 20/20] intel_iommu: Enable host device when x-flts=on in scalable mode Zhenzhong Duan
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=b3787ed4219743e2a65edd13ff44d9b9@huawei.com \
--to=qemu-devel@nongnu.org \
--cc=alex.williamson@redhat.com \
--cc=chao.p.peng@intel.com \
--cc=clement.mathieu--drif@eviden.com \
--cc=clg@redhat.com \
--cc=ddutile@redhat.com \
--cc=eric.auger@redhat.com \
--cc=jasowang@redhat.com \
--cc=jgg@nvidia.com \
--cc=joao.m.martins@oracle.com \
--cc=kevin.tian@intel.com \
--cc=mst@redhat.com \
--cc=nicolinc@nvidia.com \
--cc=peterx@redhat.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=yi.l.liu@intel.com \
--cc=zhenzhong.duan@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 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).