oops, inadvertently hit send before I could add reply... apologies... reply
below...
On 7/10/25 1:01 PM, Donald Dutile wrote:
On 7/10/25 4:11 AM, Shameerali Kolothum Thodi wrote:
-----Original Message-----
From: Nicolin Chen <nicol...@nvidia.com>
Sent: Wednesday, July 9, 2025 8:20 PM
To: Donald Dutile <ddut...@redhat.com>
Cc: Zhenzhong Duan <zhenzhong.d...@intel.com>; qemu-
de...@nongnu.org; alex.william...@redhat.com; c...@redhat.com;
eric.au...@redhat.com; m...@redhat.com; jasow...@redhat.com;
pet...@redhat.com; j...@nvidia.com; Shameerali Kolothum Thodi
<shameerali.kolothum.th...@huawei.com>; joao.m.mart...@oracle.com;
clement.mathieu--d...@eviden.com; kevin.t...@intel.com;
yi.l....@intel.com; chao.p.p...@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
Shameer,
I didn't think of these config options this way... so is this CAP always 0 for
smmuv3's associated VIOMMU?
or ... should intel-iommu follow this same/smmuv3 config option(s) and avoid
this VIOMMU CAP req. ?
- Don
