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] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit

To: Ingo Molnar <mingo@xxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Mon, 30 Jun 2008 16:04:48 -0700
Cc: Nick Piggin <npiggin@xxxxxxx>, Mark McLoughlin <markmc@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Eduardo Habkost <ehabkost@xxxxxxxxxx>, Vegard Nossum <vegard.nossum@xxxxxxxxx>, Stephen Tweedie <sct@xxxxxxxxxx>, x86@xxxxxxxxxx, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Yinghai Lu <yhlu.kernel@xxxxxxxxx>
Delivery-date: Mon, 30 Jun 2008 16:05:16 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080630092209.GA29815@xxxxxxx>
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: <20080625152212.GA3442@xxxxxxx> <4862A6A9.1030109@xxxxxxxx> <20080626105722.GA12640@xxxxxxx> <20080626105818.GA13805@xxxxxxx> <4863A8E6.1010807@xxxxxxxx> <20080627160333.GA27072@xxxxxxx> <486539A3.3030102@xxxxxxxx> <20080629084318.GA28815@xxxxxxx> <48684CD4.7040403@xxxxxxxx> <20080630082135.GA22844@xxxxxxx> <20080630092209.GA29815@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.14 (X11/20080501)
Ingo Molnar wrote:
-tip auto-testing found pagetable corruption (CPA self-test failure):

[   32.956015] CPA self-test:
[   32.958822]  4k 2048 large 508 gb 0 x 
2556[ffff880000000000-ffff88003fe00000] miss 0
[   32.964000] CPA ffff88001d54e000: bad pte 1d4000e3
[   32.968000] CPA ffff88001d54e000: unexpected level 2
[   32.972000] CPA ffff880022c5d000: bad pte 22c000e3
[   32.976000] CPA ffff880022c5d000: unexpected level 2
[   32.980000] CPA ffff8800200ce000: bad pte 200000e3
[   32.984000] CPA ffff8800200ce000: unexpected level 2
[   32.988000] CPA ffff8800210f0000: bad pte 210000e3

config and full log can be found at:

 http://redhat.com/~mingo/misc/config-Mon_Jun_30_11_11_51_CEST_2008.bad
 http://redhat.com/~mingo/misc/log-Mon_Jun_30_11_11_51_CEST_2008.bad

i've pushed that tree out into tip/tmp.xen-64bit.Mon_Jun_30_11_11. The only new item in that tree over a well-tested base is x86/xen-64bit, so i've taken it out again.

Phew. OK, I've worked this out. Short version is that's it's a false alarm, and there was no real failure here. Long version:

   * I changed the code to create the physical mapping pagetables to
     reuse any existing mapping rather than replace it.   Specifically,
     reusing an pud pointed to by the pgd caused this symptom to appear.
   * The specific PUD being reused is the one created statically in
     head_64.S, which creates an initial 1GB mapping.
   * That mapping doesn't have _PAGE_GLOBAL set on it, due to the
     inconsistency between __PAGE_* and PAGE_*.
   * The CPA test attempts to clear _PAGE_GLOBAL, and then checks to
     see that the resulting range is 1) shattered into 4k pages, and 2)
     has no _PAGE_GLOBAL.
   * However, since it didn't have _PAGE_GLOBAL on that range to start
     with, change_page_attr_clear() had nothing to do, and didn't
     bother shattering the range,
   * resulting in the reported messages

The simple fix is to set _PAGE_GLOBAL in level2_ident_pgt.

An additional fix to make CPA testing more robust by using some other pagetable bit (one of the unused available-to-software ones). This would solve spurious CPA test warnings under Xen which uses _PAGE_GLOBAL for its own purposes (ie, not under guest control).

Also, we should revisit the use of _PAGE_GLOBAL in asm-x86/pgtable.h, and use it consistently, and drop MAKE_GLOBAL. The first time I proposed it it caused breakages in the very early CPA code; with luck that's all fixed now.

Anyway, the simple fix below. I'll put together RFC patches for the other suggestions. I also split the originating patch into tiny, tiny bisectable pieces.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>

---
arch/x86/kernel/head_64.S |    2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

===================================================================
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -374,7 +374,7 @@
        /* Since I easily can, map the first 1G.
         * Don't set NX because code runs from these pages.
         */
-       PMDS(0, __PAGE_KERNEL_LARGE_EXEC, PTRS_PER_PMD)
+       PMDS(0, __PAGE_KERNEL_LARGE_EXEC | _PAGE_GLOBAL, PTRS_PER_PMD)

NEXT_PAGE(level2_kernel_pgt)
        /*



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

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