Hi Kevin, On 04/08/17 02:49, Tian, Kevin wrote: >> From: Jean-Philippe Brucker >> Sent: Tuesday, August 1, 2017 4:26 PM >> >> It depends what type you use when registering the IOMMU with >> VFIO_SET_IOMMU: >> >> * If the type is VFIO_TYPE1v2_IOMMU, then >> VFIO_IOMMU_MAP/UNMAP_DMA >> affects the stage-1 non-PASID context (already the case in mainline). >> In addition, with my patch the BIND ioctl will affect stage-1 PASID >> contexts, and bind process page directories to the device (host SVM). >> >> * If the type is VFIO_TYPE1_NESTING_IOMMU, then >> VFIO_IOMMU_MAP/UNMAP_DMA >> will affect stage-2 mappings (already in mainline). >> With my SMMU patch series, the BIND ioctl is not supported in this mode. >> But in the future, BIND would allow to manage stage-1 as well: >> - bind a process page directory (host SVM with added stage-2), or > > I thought host SVM will only go through VFIO_TYPE1v2_IOMMU, > since you said stage-2 in ARM SMMU is only for GPA->HPA usage > in previous explanation. then what does "host SVM with added > stage-2" mean here? Ah, that's just a crazy idea I had. I'm not sure it is useful or worth implementing, but it is one of the possibility offered by nested translation. Consider the situation where a userspace driver (no virtualization) is built in a client-server fashion: the server controls a device and spawns new processes (clients), each sharing a context with the device using its own PASID. If the server wants to hide parts of the client address space from the device (e.g. .text), then it could control stage-2 via MAP/UNMAP to restrict the address space. It would use different semantics of MAP/UNMAP though, as the ioctl would only be used to define 1:1 translation windows, not pin memory. Thanks, Jean
