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: Thu, 29 Sep 2011 17:45:52 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Konrad
Delivery-date: Thu, 29 Sep 2011 09:46:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E84B3FE02000078000588A9@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>
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 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.

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

David

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