> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker@xxxxxxx] > Sent: Friday, August 4, 2017 5:43 PM > > 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. stage-1 is linked to CPU page table (VA->PA) for SVM, while physical memory is managed by kernel. I didn't come up a good reason why server application needs or has knowledge to hide some resource which is not managed by itself... > > 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
