[PATCH] xen: remove support for non-PAE 32-bit - Kernel

This is a discussion on [PATCH] xen: remove support for non-PAE 32-bit - Kernel ; Non-PAE operation has been deprecated in Xen for a while, and is rarely tested or used. xen-unstable has now officially dropped non-PAE support. Since Xen/pvops' non-PAE support has also been broken for a while, we may as well completely drop ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: [PATCH] xen: remove support for non-PAE 32-bit

  1. [PATCH] xen: remove support for non-PAE 32-bit

    Non-PAE operation has been deprecated in Xen for a while, and is
    rarely tested or used. xen-unstable has now officially dropped
    non-PAE support. Since Xen/pvops' non-PAE support has also been
    broken for a while, we may as well completely drop it altogether.

    Signed-off-by: Jeremy Fitzhardinge
    ---
    arch/x86/xen/Kconfig | 2 -
    arch/x86/xen/enlighten.c | 51 +++++++++++++++-----------------------------
    arch/x86/xen/mmu.c | 19 +---------------
    arch/x86/xen/mmu.h | 24 +++++---------------
    arch/x86/xen/xen-head.S | 4 ---
    include/asm-x86/xen/page.h | 4 ---
    6 files changed, 27 insertions(+), 77 deletions(-)

    ================================================== =================
    --- a/arch/x86/xen/Kconfig
    +++ b/arch/x86/xen/Kconfig
    @@ -6,7 +6,7 @@
    bool "Xen guest support"
    select PARAVIRT
    depends on X86_32
    - depends on X86_CMPXCHG && X86_TSC && !(X86_VISWS || X86_VOYAGER)
    + depends on X86_CMPXCHG && X86_TSC && X86_PAE && !(X86_VISWS || X86_VOYAGER)
    help
    This is the Linux Xen port. Enabling this will allow the
    kernel to boot in a paravirtualized environment under the
    ================================================== =================
    --- a/arch/x86/xen/enlighten.c
    +++ b/arch/x86/xen/enlighten.c
    @@ -811,38 +811,35 @@
    static __init void xen_pagetable_setup_start(pgd_t *base)
    {
    pgd_t *xen_pgd = (pgd_t *)xen_start_info->pt_base;
    + int i;

    /* special set_pte for pagetable initialization */
    pv_mmu_ops.set_pte = xen_set_pte_init;

    init_mm.pgd = base;
    /*
    - * copy top-level of Xen-supplied pagetable into place. For
    - * !PAE we can use this as-is, but for PAE it is a stand-in
    - * while we copy the pmd pages.
    + * copy top-level of Xen-supplied pagetable into place. This
    + * is a stand-in while we copy the pmd pages.
    */
    memcpy(base, xen_pgd, PTRS_PER_PGD * sizeof(pgd_t));

    - if (PTRS_PER_PMD > 1) {
    - int i;
    - /*
    - * For PAE, need to allocate new pmds, rather than
    - * share Xen's, since Xen doesn't like pmd's being
    - * shared between address spaces.
    - */
    - for (i = 0; i < PTRS_PER_PGD; i++) {
    - if (pgd_val_ma(xen_pgd[i]) & _PAGE_PRESENT) {
    - pmd_t *pmd = (pmd_t *)alloc_bootmem_low_pages(PAGE_SIZE);
    + /*
    + * For PAE, need to allocate new pmds, rather than
    + * share Xen's, since Xen doesn't like pmd's being
    + * shared between address spaces.
    + */
    + for (i = 0; i < PTRS_PER_PGD; i++) {
    + if (pgd_val_ma(xen_pgd[i]) & _PAGE_PRESENT) {
    + pmd_t *pmd = (pmd_t *)alloc_bootmem_low_pages(PAGE_SIZE);

    - memcpy(pmd, (void *)pgd_page_vaddr(xen_pgd[i]),
    - PAGE_SIZE);
    + memcpy(pmd, (void *)pgd_page_vaddr(xen_pgd[i]),
    + PAGE_SIZE);

    - make_lowmem_page_readonly(pmd);
    + make_lowmem_page_readonly(pmd);

    - set_pgd(&base[i], __pgd(1 + __pa(pmd)));
    - } else
    - pgd_clear(&base[i]);
    - }
    + set_pgd(&base[i], __pgd(1 + __pa(pmd)));
    + } else
    + pgd_clear(&base[i]);
    }

    /* make sure zero_page is mapped RO so we can use it in pagetables */
    @@ -899,17 +896,7 @@

    /* Actually pin the pagetable down, but we can't set PG_pinned
    yet because the page structures don't exist yet. */
    - {
    - unsigned level;
    -
    -#ifdef CONFIG_X86_PAE
    - level = MMUEXT_PIN_L3_TABLE;
    -#else
    - level = MMUEXT_PIN_L2_TABLE;
    -#endif
    -
    - pin_pagetable_pfn(level, PFN_DOWN(__pa(base)));
    - }
    + pin_pagetable_pfn(MMUEXT_PIN_L3_TABLE, PFN_DOWN(__pa(base)));
    }

    /* This is called once we have the cpu_possible_map */
    @@ -1119,7 +1106,6 @@
    .make_pte = xen_make_pte,
    .make_pgd = xen_make_pgd,

    -#ifdef CONFIG_X86_PAE
    .set_pte_atomic = xen_set_pte_atomic,
    .set_pte_present = xen_set_pte_at,
    .set_pud = xen_set_pud,
    @@ -1128,7 +1114,6 @@

    .make_pmd = xen_make_pmd,
    .pmd_val = xen_pmd_val,
    -#endif /* PAE */

    .activate_mm = xen_activate_mm,
    .dup_mmap = xen_dup_mmap,
    ================================================== =================
    --- a/arch/x86/xen/mmu.c
    +++ b/arch/x86/xen/mmu.c
    @@ -222,7 +222,7 @@
    ret = machine_to_phys(XMADDR(ret)).paddr | _PAGE_PRESENT;
    return ret;
    }
    -#ifdef CONFIG_X86_PAE
    +
    void xen_set_pud(pud_t *ptr, pud_t val)
    {
    struct multicall_space mcs;
    @@ -272,12 +272,6 @@

    return native_make_pmd(pmd);
    }
    -#else /* !PAE */
    -void xen_set_pte(pte_t *ptep, pte_t pte)
    -{
    - *ptep = pte;
    -}
    -#endif /* CONFIG_X86_PAE */

    /*
    (Yet another) pagetable walker. This one is intended for pinning a
    @@ -430,8 +424,6 @@
    read-only, and can be pinned. */
    void xen_pgd_pin(pgd_t *pgd)
    {
    - unsigned level;
    -
    xen_mc_batch();

    if (pgd_walk(pgd, pin_page, TASK_SIZE)) {
    @@ -441,14 +433,7 @@
    xen_mc_batch();
    }

    -#ifdef CONFIG_X86_PAE
    - level = MMUEXT_PIN_L3_TABLE;
    -#else
    - level = MMUEXT_PIN_L2_TABLE;
    -#endif
    -
    - xen_do_pin(level, PFN_DOWN(__pa(pgd)));
    -
    + xen_do_pin(MMUEXT_PIN_L3_TABLE, PFN_DOWN(__pa(pgd)));
    xen_mc_issue(0);
    }

    ================================================== =================
    --- a/arch/x86/xen/mmu.h
    +++ b/arch/x86/xen/mmu.h
    @@ -37,14 +37,13 @@
    void xen_pgd_pin(pgd_t *pgd);
    //void xen_pgd_unpin(pgd_t *pgd);

    -#ifdef CONFIG_X86_PAE
    -unsigned long long xen_pte_val(pte_t);
    -unsigned long long xen_pmd_val(pmd_t);
    -unsigned long long xen_pgd_val(pgd_t);
    +pteval_t xen_pte_val(pte_t);
    +pmdval_t xen_pmd_val(pmd_t);
    +pgdval_t xen_pgd_val(pgd_t);

    -pte_t xen_make_pte(unsigned long long);
    -pmd_t xen_make_pmd(unsigned long long);
    -pgd_t xen_make_pgd(unsigned long long);
    +pte_t xen_make_pte(pteval_t);
    +pmd_t xen_make_pmd(pmdval_t);
    +pgd_t xen_make_pgd(pgdval_t);

    void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
    pte_t *ptep, pte_t pteval);
    @@ -53,15 +52,4 @@
    void xen_pte_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep);
    void xen_pmd_clear(pmd_t *pmdp);

    -
    -#else
    -unsigned long xen_pte_val(pte_t);
    -unsigned long xen_pmd_val(pmd_t);
    -unsigned long xen_pgd_val(pgd_t);
    -
    -pte_t xen_make_pte(unsigned long);
    -pmd_t xen_make_pmd(unsigned long);
    -pgd_t xen_make_pgd(unsigned long);
    -#endif
    -
    #endif /* _XEN_MMU_H */
    ================================================== =================
    --- a/arch/x86/xen/xen-head.S
    +++ b/arch/x86/xen/xen-head.S
    @@ -30,11 +30,7 @@
    ELFNOTE(Xen, XEN_ELFNOTE_ENTRY, .long startup_xen)
    ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, .long hypercall_page)
    ELFNOTE(Xen, XEN_ELFNOTE_FEATURES, .asciz "!writable_page_tables|pae_pgdir_above_4gb")
    -#ifdef CONFIG_X86_PAE
    ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE, .asciz "yes")
    -#else
    - ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE, .asciz "no")
    -#endif
    ELFNOTE(Xen, XEN_ELFNOTE_LOADER, .asciz "generic")

    #endif /*CONFIG_XEN */
    ================================================== =================
    --- a/include/asm-x86/xen/page.h
    +++ b/include/asm-x86/xen/page.h
    @@ -150,13 +150,9 @@
    return (pte_t) { .pte = x };
    }

    -#ifdef CONFIG_X86_PAE
    #define pmd_val_ma(v) ((v).pmd)
    #define pud_val_ma(v) ((v).pgd.pgd)
    #define __pmd_ma(x) ((pmd_t) { (x) } )
    -#else /* !X86_PAE */
    -#define pmd_val_ma(v) ((v).pud.pgd.pgd)
    -#endif /* CONFIG_X86_PAE */

    #define pgd_val_ma(x) ((x).pgd)



    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH] xen: remove support for non-PAE 32-bit


    * Jeremy Fitzhardinge wrote:

    > Non-PAE operation has been deprecated in Xen for a while, and is
    > rarely tested or used. xen-unstable has now officially dropped
    > non-PAE support. Since Xen/pvops' non-PAE support has also been
    > broken for a while, we may as well completely drop it altogether.


    applied, thanks.

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [Xen-devel] Re: [PATCH] xen: remove support for non-PAE 32-bit

    Robert Kaiser (FH) wrote:
    > Hmm, I had to revert to non-PAE operation (using xen 3.2.1) recently in order
    > to get Xen to run under qemu. Does anyone know of another work-around to run
    > Xen/Linux under qemu?


    In principle it should work in PAE mode; it certainly works in kvm.
    What problem are you seeing? I think there's a bug in qemu's x86
    emulation with respect to mis-reporting the eip of an xchg which faults,
    which may be what you're seeing.

    J

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [Xen-devel] Re: [PATCH] xen: remove support for non-PAE 32-bit

    Hi,

    Am Dienstag 13 Mai 2008 13:08 schrieb Ingo Molnar:
    > * Jeremy Fitzhardinge wrote:
    > > Non-PAE operation has been deprecated in Xen for a while, and is
    > > rarely tested or used. xen-unstable has now officially dropped
    > > non-PAE support. Since Xen/pvops' non-PAE support has also been
    > > broken for a while, we may as well completely drop it altogether.

    >
    > applied, thanks.


    Hmm, I had to revert to non-PAE operation (using xen 3.2.1) recently in order
    to get Xen to run under qemu. Does anyone know of another work-around to run
    Xen/Linux under qemu?

    Rob

    --
    Robert Kaiser http://wwwvs.informatik.fh-wiesbaden.de
    Labor für Verteilte Systeme kaiser@informatik.fh-wiesbaden.de
    FH Wiesbaden - University of Applied Sciences tel: (+49)611-9495-294
    Kurt-Schumacher-Ring 18, 65197 Wiesbaden, Germany fax: (+49)611-9495-294
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [Xen-devel] Re: [PATCH] xen: remove support for non-PAE 32-bit

    Am Dienstag 13 Mai 2008 13:48 schrieb Jeremy Fitzhardinge:
    > Robert Kaiser (FH) wrote:
    > > Hmm, I had to revert to non-PAE operation (using xen 3.2.1) recently in
    > > order to get Xen to run under qemu. Does anyone know of another
    > > work-around to run Xen/Linux under qemu?

    >
    > In principle it should work in PAE mode;


    I thought so, too, however it doesn't :-(.

    > it certainly works in kvm.
    > What problem are you seeing?


    Linux crashes just after the message "Freeing unused
    kernel memory: ..." due to dereferencing a bad address.

    The following is from the top of my head (if you need more details, let me kow
    and I'll recompile everything with PAE so I can reproduce the problem again
    -- this will take some time though..):

    The crash results from a call to do_munmap(). Strangely though, when setting a
    breakpoint at the faulting assembly instruction (I'm using qemu's debug stub
    facility) , the problem disappears: the address being dereferenced (contained
    in register eax) is always a valid one. However, as soon as I remove that
    breakpoint and hit "continue", it does crash again with the crash dump
    showing an eip pointing to where the breakpoint formerly was, and an invalid
    address in eax.

    > I think there's a bug in qemu's x86
    > emulation with respect to mis-reporting the eip of an xchg which faults,
    > which may be what you're seeing.


    The eip that was reported was always the same, and there was no xchg
    instruction at that address. It might have been consistently wrong though
    (how would I figure this out?).


    Rob

    --
    Robert Kaiser http://wwwvs.informatik.fh-wiesbaden.de
    Labor für Verteilte Systeme kaiser@informatik.fh-wiesbaden.de
    FH Wiesbaden - University of Applied Sciences tel: (+49)611-9495-294
    Kurt-Schumacher-Ring 18, 65197 Wiesbaden, Germany fax: (+49)611-9495-294
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [Xen-devel] Re: [PATCH] xen: remove support for non-PAE 32-bit

    Robert Kaiser (FH) wrote:
    >> I think there's a bug in qemu's x86
    >> emulation with respect to mis-reporting the eip of an xchg which faults,
    >> which may be what you're seeing.
    >>

    >
    > The eip that was reported was always the same, and there was no xchg
    > instruction at that address. It might have been consistently wrong though
    > (how would I figure this out?).
    >


    The symptom I've observed is that qemu reports the first instruction of
    the basic block rather than the exchange itself. If you "x/10i eip>", you should see an xchg before long.

    Either way, sounds like a qemu bug which should be reported to them.

    J
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread