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. > 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. > 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. > 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
