Re: [Xen-devel] [PATCH 0/4] xen: map foreign pages for shared rings by updating the PTEs directly

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2011-09-30 at 09:08 +0100, Jan Beulich wrote:
> >>> On 29.09.11 at 18:45, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> > On 29/09/11 17:07, Jan Beulich wrote:
> >>>>> On 29.09.11 at 17:53, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> >>> [Resend as requested by Konrad.]
> >>>
> >>> This series of patches allows the vmalloc_sync_all() to be removed
> >>> from alloc_vm_area() by getting the hypervisor to update the PTEs (in
> >>> init_mm) directly rather than having the hypervisor look in the
> >>> current page tables to find the PTEs.
> >>>
> >>> Once the hypervisor has updated the PTEs, the normal mechanism of
> >>> syncing the page tables after a fault works as expected.
> >> 
> >> Did you actually test that, and namely the case where alloc_vm_area()
> >> would result in a new top level page directory entry to get populated?
> >>
> >> I cannot see how this new entry would propagate into other mm-s, and
> >> hence I cannot see how you can do away with calling vmalloc_sync_all()
> >> just by changing how leaf page table entries get populated.
> > 
> > I don't think this new behaviour of alloc_vm_area() is any different
> > from how a regular vmalloc() works.
> 
> Of course not. Callers of vmalloc() need to use vmalloc_sync_all() too
> before it is permitted to access the allocated space from an NMI
> handler or pass it into a hypercall.
> 
> > vmalloc_fault() copies the page table entries from init_mm into the
> > current MM (on 32-bit it calls vmalloc_sync_one() which makes it
> > obviously correct I think).
> 
> No, vmalloc_fault() copies pmd-s (32-bit) or pgd-s (64-bit), but never
> pte-s.

Right, but David has also changed the hypercall so that it now takes the
specific pte to update, instead of taking the virtual address and
relying on the hypervisor's linear map of the guests page tables to do
the update.

So the hypercall can now update the pte regardless of whether it is
actually hooked into the current set of page tables or not.

Then once the hypercall is complete and the kernel comes to actually use
the address the normal vmalloc fault stuff will happen and fault in the
pmd/pgd which refers to those ptes which have been updated.

Ian.

>  Avoiding this to be done in a fault (precisely for the NMI and
> hypercall cases named above) is what vmalloc_sync_all() was
> introduced for (really, the hypercall aspect didn't matter back then,
> and alloc_vm_area() didn't exist outside of Xenolinux then either).
> 
> So eliminating it from alloc_vm_area() just pushes the need to call it
> to all callers that may have the obtained space accessed in NMI
> context (none at present, as only Xen code appears to call this
> function) or want to pass it to a hypercall without running on init_mm.
> 
> Just to repeat the essence of my first reply: Fiddling with how pte-s
> get populated can not possibly eliminate the need to call a function
> that populates top level page directory entries (pmd-s/pgd-s).
> 
> Jan
> 
> >>> This mechanism doesn't currently work on the ia64 port as that does
> >>> not support the GNTMAP_contains_pte flag.
> >>>
> >>> David
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel