> From: Tian, Kevin <kevin.tian@xxxxxxxxx> > Sent: Wednesday, June 21, 2023 2:02 PM > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > 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
