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] dom0 pvops crash

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] dom0 pvops crash
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Wed, 27 Jan 2010 17:26:13 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Wed, 27 Jan 2010 09:26:38 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B5DF8E5.9040906@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>
Organization: Citrix Systems, Inc.
References: <C783A22C.7599%keir.fraser@xxxxxxxxxxxxx> <4B5DF8E5.9040906@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, 2010-01-25 at 20:02 +0000, Jeremy Fitzhardinge wrote:
> 
> IanC, Pasi, myself and others explored a number of other ways to try
> and fix it in the Xen pvops code, but they all turned out to be very 
> expensive, just not work (they just pushed the race around), or
> require new pvops just for this case.

Just to brainstorm a bit more:

There's no way a kunmap_atomic pvop would be acceptable? it would at
least make the API symmetrical.

What about a hypercall which would set a PTE with the writable bit set
atomically depending on the pinned status of the referenced page? (I
haven't even vaguely thought this idea through).

Is there some way we can disable HIGHPTE at runtime even if
CONFIG_HIGHPTE=y? Looks like that might be relatively self-contained in
pte_alloc_one(). All the actual uses of high PTEs goes through
kmap_atomic which explicitly tests for PageHighmem so by ensuring PTEs
are never high at allocation time we would skip all those paths.
Something like the untested patch below, but not so skanky, obviously.

This last would be nice since it also remove the
crippling-for-virtualisation overhead, so it would potentially benefit
KVM and VMI as well...

> Given that HIGHPTE is generally a bad idea and should be deprecated
> (any machine big enough to need it should definitely be running a
> 64-bit kernel), I've left it on the backburner hoping for some
> inspiration to strike.  So far it has not. 

Unfortunately distros seem to be using it for their native kernels and
since pvops means they won't have a separate xen kernel I think we need
to figure something out.

Ian.

diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index 65215ab..49f8e83 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -28,7 +28,10 @@ pgtable_t pte_alloc_one(struct mm_struct *mm, unsigned long 
address)
        struct page *pte;
 
 #ifdef CONFIG_HIGHPTE
-       pte = alloc_pages(PGALLOC_GFP | __GFP_HIGHMEM, 0);
+       if (is_xen_domain())
+               pte = alloc_pages(PGALLOC_GFP, 0);
+       else
+               pte = alloc_pages(PGALLOC_GFP | __GFP_HIGHMEM, 0);
 #else
        pte = alloc_pages(PGALLOC_GFP, 0);
 #endif




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