WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 0/4] xen: map foreign pages for shared rings by u

To: Jan Beulich <JBeulich@xxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/4] xen: map foreign pages for shared rings by updating the PTEs directly
From: David Vrabel <david.vrabel@xxxxxxxxxx>
Date: Fri, 30 Sep 2011 11:14:47 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, KonradRzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Fri, 30 Sep 2011 03:14:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E85951B0200007800058AF8@xxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1317311612-15220-1-git-send-email-david.vrabel@xxxxxxxxxx> <4E84B3FE02000078000588A9@xxxxxxxxxxxxxxxxxxxx> <4E84A0C0.6000804@xxxxxxxxxx> <4E85951B0200007800058AF8@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11
On 30/09/11 09:08, 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.

The virtual addresses of the mapped rings are not accessed in an NMI
handler or a hypercall (before this patch set they were accessed in the
GNTTABOP_map_grant_ref hypercall, but no longer).

In the future, if something did want to pass the virtual address to a
hypercall it wouldn't need the vmalloc_sync() as it could disable
preemption, touch the page (so current->active_mm is updated), do the
hypercall, then disable preemption.

>> 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. 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