From: Eric Auger <eric.auger@redhat.com>
To: Donald Dutile <ddutile@redhat.com>, Nicolin Chen <nicolinc@nvidia.com>
Cc: Zhenzhong Duan <zhenzhong.duan@intel.com>,
qemu-devel@nongnu.org, alex.williamson@redhat.com,
clg@redhat.com, mst@redhat.com, jasowang@redhat.com,
peterx@redhat.com, jgg@nvidia.com,
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()
Date: Tue, 15 Jul 2025 17:28:54 +0200 [thread overview]
Message-ID: <b8c3b228-953f-4364-b78f-2702ae2bd183@redhat.com> (raw)
In-Reply-To: <0c99b6aa-440a-44df-b875-a34e64465a04@redhat.com>
Hi,
On 7/10/25 3:22 AM, Donald Dutile wrote:
>
>
> On 7/9/25 3:20 PM, Nicolin Chen wrote:
>> 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"?
>>
>> Thanks
>> Nicolin
>>
> If the distinction is hw-based s1 vs emulated-based s1, than
> I'd prefer the use of VIOMMU_CAP_HW_NESTED_S1, and avoid the use
VIOMMU_CAP_HW_NESTED_S1 or even VIOMMU_CAP_HW_NESTED look good to me too
Thanks
Eric
> of 'accel'/'ACCEL' unless it is an explicitly stated 'acceleration'
> feature/option in the SMMU spec.
>
> Thanks,
> - Don
>
next prev parent reply other threads:[~2025-07-15 15:58 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 [this message]
2025-07-15 16:42 ` Donald Dutile
2025-07-10 8:11 ` Shameerali Kolothum Thodi via
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=b8c3b228-953f-4364-b78f-2702ae2bd183@redhat.com \
--to=eric.auger@redhat.com \
--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=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=qemu-devel@nongnu.org \
--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).