On Fri, Aug 04, 2017 at 10:42:41AM +0100, Jean-Philippe Brucker wrote: > Hi Kevin, > > > 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 Just to be sure, you are't expecting the PASID's to be duplicated or recreated after a new process is spawned. I would expect each process to get its own PASID by doing a bind. Threads of the same process would be sharing the same PASID since they all share the same first level mappings. > from the device (e.g. .text), then it could control stage-2 via MAP/UNMAP > to restrict the address space. I'm confused.. maybe this is different from Intel IOMMU. the first level requiring a second level is only true when virtualization is in play. First level is gVA->gPA, and second level is gPA->hPA (sort of the cloned EPT map that is setup via VFIO to set up second level) When you are in native user application, there is no nesting between first and second level. The first level is directly VA->hPA. There is no need for a nested walk in this case? > > 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. >
