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

[Xen-devel] Re: [PATCH 0/6] xen: don't call vmalloc_sync_all() when mapp

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 0/6] xen: don't call vmalloc_sync_all() when mapping foreign pages
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Wed, 21 Sep 2011 11:42:01 +0100
Cc: "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, David Vrabel <david.vrabel@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Wed, 21 Sep 2011 03:43:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E727017.4030001@xxxxxxxx>
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: <1316090411-22608-1-git-send-email-david.vrabel@xxxxxxxxxx> <4E727017.4030001@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Thu, 15 Sep 2011, Jeremy Fitzhardinge wrote:
> On 09/15/2011 05:40 AM, David Vrabel wrote:
> > This set of pages avoids the need to call vmalloc_sync_all() when
> > mapping foreign pages.  Two new functions are adding for mapping
> > foreign pages onto RAM pages instead of vmalloc space.
> >
> > This does waste a page of RAM for each mapped page.  In the future a
> > ballooned page could be used instead (once the API for getting a
> > ballooned page with the right GFP flags is available).
> 
> You can allocate a pfn, free ("balloon out") the underlying mfn, and
> replace it with a granted page; it doesn't need any particular new
> infrastructure.

David, give a look at drivers/xen/balloon.c:alloc_xenballooned_pages, in
particular after my changes to it:

http://marc.info/?l=linux-kernel&m=131552369305998&w=2

it allows the caller to allocate a lowmem page and balloon it out right
away.


> But that said, if you want to allocate virtual addresses for mapping
> granted pages, then alloc_vm_area() is the right thing to use.  You need
> to make sure you touch the pages from within the kernel before passing
> those addresses to a hypercall to make sure the mappings are established
> within the current task (possibly within a no-preempt region to
> guarantee that nothing odd happens).  Or alternatively, you could switch
> the current pagetable to init_mm for the hypercall (if it isn't already)
> - since that's the reference pagetable - assuming you're not passing
> usermode virtual addresses to the hypercall.

This problem is not very different from the one we are trying to solve
with alloc_xenballooned_pages: in case we want a page that is mapped in
kernel space we just use allocate a lowmem page, balloon it out, change
the p2m and add the page to the m2p_override.
Why should we solve that issue differently?


> This series is relying on regular ram mappings are already synced to all
> tasks, but I'm not sure that's necessarily guaranteed (for example, if
> you hotplug new memory into the domain, the new pages won't be mapped
> into every mm unless they're synced).

the series is using GFP_KERNEL, so this problem shouldn't occur, right?

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

<Prev in Thread] Current Thread [Next in Thread>