From: Jason Gunthorpe jgg@nvidia.com Sent: Wednesday, June 21, 2023 8:05 PM
On Wed, Jun 21, 2023 at 06:02:21AM +0000, Tian, Kevin wrote:
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.
In any nesting configuration the hypervisor cannot directly restrict what IOVA the guest will use. The VM could make a normal nest and try to use unusable IOVA. Identity is not really special.
Sure. What I talked is the end result e.g. after the user explicitly requests to load reserved regions into an IOAS.
The VMM should construct the guest memory map so that an identity iommu_domain can meet the reserved requirements - it needs to do this anyhow for the initial boot part. It shouuld try to forward the reserved regions to the guest via ACPI/etc.
Yes.
Being able to explicitly load reserved regions into an IOAS seems like a useful way to help construct this.
And it's correct in concept because the IOAS is 'implicitly' accessed by the device when the guest domain is identity in this case.