From: Tian, Kevin kevin.tian@intel.com Sent: Wednesday, June 21, 2023 2:02 PM
From: Jason Gunthorpe jgg@nvidia.com Sent: Tuesday, June 20, 2023 8:47 PM
On Tue, Jun 20, 2023 at 01:43:42AM +0000, Tian, Kevin wrote:
I wonder whether we have argued passed each other.
This series adds reserved regions to S2. I challenged the necessity as S2 is not directly accessed by the device.
Then you replied that doing so still made sense to support identity S1.
I think I said/ment if we attach the "s2" iommu domain as a direct attach for identity - eg at boot time, then the IOAS must gain the reserved regions. This is our normal protocol.
But when we use the "s2" iommu domain as an actual nested S2 then we don't gain reserved regions.
Then we're aligned.
Yi/Nicolin, please update this series to not automatically add reserved regions to S2 in the nesting configuration.
Got it.
It also implies that the user cannot rely on IOAS_IOVA_RANGES to learn reserved regions for arranging addresses in S1.
Then we also need a new ioctl to report reserved regions per dev_id.
Shall we add it now? I suppose yes.
Intel VT-d supports 4 configurations:
- passthrough (i.e. identity mapped)
- S1 only
- S2 only
- nested
'S2 only' is used when vIOMMU is configured in passthrough.
S2 only is modeled as attaching an S2 format iommu domain to the RID, and when this is done the IOAS should gain the reserved regions because it is no different behavior than attaching any other iommu domain to a RID.
When the S2 is replaced with a S1 nest then the IOAS should loose those reserved regions since it is no longer attached to a RID.
yes
Makes sense.
Regards, Yi Liu
My understanding of ARM SMMU is that from host p.o.v. the CD is the S1 in the nested configuration. 'identity' is one configuration in the CD then it's in the business of nesting.
I think it is the same. A CD doesn't come into the picture until the guest installs a CD pointing STE. Until that time the S2 is being used as identity.
It sounds like the same basic flow.
After a CD table is installed in a STE I assume the SMMU still allows to configure an individual CD entry as identity? e.g. while vSVA is enabled on a device the guest can continue to keep CD#0 as identity when the default domain of the device is set as 'passthrough'. In this case the IOAS still needs to gain reserved regions even though S2 is not directly attached from host p.o.v.
My preference was that ALLOC_HWPT allows vIOMMU to opt whether reserved regions of dev_id should be added to the IOAS of the parent S2 hwpt.
Having an API to explicitly load reserved regions of a specific device to an IOAS makes some sense to me.
Jason