On 5/26/06, Vivek Goyal <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
