[lkml]   [2006]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Fastboot] [PATCH 03/03] kexec: Avoid overwriting the current pgd (V2, x86_64)
    On 5/26/06, Vivek Goyal <> wrote:
    > On Thu, May 25, 2006 at 05:26:56PM +0900, Magnus Damm wrote:
    > > So, to answer your question regarding two page table copies. You may be
    > > right that it can be made work with just one page table, but I feel my
    > > two table approach is nice because it will always work - regardless of
    > > the memory map used.
    > So you seem to be suggesting that code can be made to work (even with Xen)
    > with single identity mapped page table as used currently but it would fail
    > in certain circumstances (different memory map used). Can you please explain
    > a little more how?

    Sorry about the delay, your question needed some thinking.

    I do not think that vanilla kexec x86_64 has any memory map related
    problems, apart for the page table overwriting. And the page table
    overwriting is not a bug that will make kdump fail, it just makes the
    memory image less accurate. I do however think the accuracy is quite
    important given that kdump mainly is used for memory image collection.

    The main reason for using two sets of page tables is simplicity. The
    page_table_a code for allocation and page table setup is more or less
    identical for i386 and x86_64. The code was written to be generic, but
    during the testing I realized that the architecture-specific header
    files defined things differently so I needed to add some
    architecture-specific macros as workarounds. It should be possible to
    share the code in a common file.

    Simon and I have tried to make the Xen port of kexec as simple as
    possible. One design decision that I know Eric dislikes is the array
    of pages for page_table_a. The reason behind this array is simplicity,
    especially for our Xen port.

    Our Xen port makes the dom0 kernel responsible for allocating pages.
    These pages are then used by the hypervisor. Some of these pages are
    page_table_a pages, and these pages are overwritten by the hypervisor
    with mappings that fit the memory map used by Xen. If we would pass
    the root pointer instead of an array of pages then the hypervisor
    would have to be extended to include code to parse page tables,
    extract pages and then fill in the new page table. That would be all
    but simple.

    Using a single page table with Xen would probably result in a more
    complex solution - the hypervisor code must be able to parse both page
    tables with both huge and normal pages. I feel that such a solution is
    error prone and overly complex. Especially since we already have
    something that works.

    I must admit that I got a bit scared of all the different page table
    modes that Xen can run in. If and how they can affect the memory map
    is beyond me. So instead of thinking of _how_ the memory maps are
    arranged under x86_64, i386, i386/pae using all config options I
    thought it was better to write something generic.
    That's how the page_table_a strategy came up. It came up as a way of
    jumping to a physical address from any virtual address, regardless of
    memory map.

    > This might be a very stupid question given the fact I am blissfully unaware
    > of all the details of Xen.

    No worries. "blissfully unaware of all the details of xen"... you
    lucky bastard! =)

    Thank you for your comments!

    / magnus
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-05-26 12:45    [W:0.022 / U:15.152 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site