> From: Raj, Ashok > Sent: Saturday, August 12, 2017 12:25 AM > > 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? > Strictly speaking nesting is just a hardware capability while virtualization is an use case using that capability. As long as some software entity (not hypervisor) can setup two level page tables, it should just work regardless of how the intermediate address is called. I think Jean is trying to come up a non-virtualization usage using nesting. Of course current example that he illustrated is not very meaningful (as I replied in another mail). :-) Thanks Kevin
