> From: Auger Eric > Sent: Friday, August 31, 2018 9:52 PM > > Hi Jean-Philippe, > > On 08/31/2018 03:11 PM, Jean-Philippe Brucker wrote: > > Hi Eric, > > > > On 23/08/18 16:25, Auger Eric wrote: > >>> +int iommu_bind_guest_stage(struct iommu_domain *domain, struct > device *dev, > >>> + struct iommu_guest_stage_config *cfg) > > > > About the name change from iommu_bind_pasid_table: is the intent to > > reuse this API for SMMUv2, which supports nested but not PASID? Seems > > like a good idea but "iommu_bind_table" may be better since "stage" is > > only used by Arm. > > At the moment I don't target SMUv2 but just SMMUv3. My focus was on > nested stage enablement without enabling the multi-CD feature (PASID), > whish is not supported by the QEMU vSMMUv3. Afterwards I realized that > basically we are pointing to a CD or PASID table and that's about the > same. I don't have a strong opinion on the name, iommu_bind_guest_table > or iommu_bind_pasid_table would be fine with me. Indeed "stage" is ARM > vocable (level for Intel?) Intel uses first level/second level. iommu_bind_table is a bit confusing. what should people take table as? there is PASID table. there is also page table linked in each stage/level. and maybe other tables in vendor-specific definition. to me iommu_bind_pasid_table is still clearer. anyway in other places we've used pasid explicitly in vfio/iommu APIs, then it should be general enough to represent various implementations. Thanks Kevin
