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: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] dom0 pvops crash
From: Pasi Kärkkäinen <pasik@xxxxxx>
Date: Sun, 7 Feb 2010 21:35:17 +0200
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Sun, 07 Feb 2010 11:35:35 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1264613173.16526.97718.camel@xxxxxxxxxxxxxxxxxxxxxx>
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: <C783A22C.7599%keir.fraser@xxxxxxxxxxxxx> <4B5DF8E5.9040906@xxxxxxxx> <1264613173.16526.97718.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
On Wed, Jan 27, 2010 at 05:26:13PM +0000, Ian Campbell wrote:
> 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
> 

I just tried this patch, but it fails to compile:

arch/x86/mm/pgtable.c: In function 'pte_alloc_one':
arch/x86/mm/pgtable.c:19: error: implicit declaration of function 
'is_xen_domain'
make[2]: *** [arch/x86/mm/pgtable.o] Error 1
make[1]: *** [arch/x86/mm] Error 2
make: *** [arch/x86] Error 2

I tried grepping around for that function but didn't find it from any header..

-- Pasi


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