aboutsummaryrefslogtreecommitdiffstats
path: root/arch/x86/xen/setup.c
diff options
context:
space:
mode:
authorKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>2012-08-22 13:00:10 -0400
committerKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>2012-08-23 11:33:27 -0400
commit51faaf2b0d5c7f44d82964f0c70b1c4e44d4e633 (patch)
tree7baa22c81606ceeb19e61d2023cc519869501fa1 /arch/x86/xen/setup.c
parent806c312e50f122c47913145cf884f53dd09d9199 (diff)
Revert "xen/x86: Workaround 64-bit hypervisor and 32-bit initial domain." and "xen/x86: Use memblock_reserve for sensitive areas."
This reverts commit 806c312e50f122c47913145cf884f53dd09d9199 and commit 59b294403e9814e7c1154043567f0d71bac7a511. And also documents setup.c and why we want to do it that way, which is that we tried to make the the memblock_reserve more selective so that it would be clear what region is reserved. Sadly we ran in the problem wherein on a 64-bit hypervisor with a 32-bit initial domain, the pt_base has the cr3 value which is not neccessarily where the pagetable starts! As Jan put it: " Actually, the adjustment turns out to be correct: The page tables for a 32-on-64 dom0 get allocated in the order "first L1", "first L2", "first L3", so the offset to the page table base is indeed 2. When reading xen/include/public/xen.h's comment very strictly, this is not a violation (since there nothing is said that the first thing in the page table space is pointed to by pt_base; I admit that this seems to be implied though, namely do I think that it is implied that the page table space is the range [pt_base, pt_base + nt_pt_frames), whereas that range here indeed is [pt_base - 2, pt_base - 2 + nt_pt_frames), which - without a priori knowledge - the kernel would have difficulty to figure out)." - so lets just fall back to the easy way and reserve the whole region. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Diffstat (limited to 'arch/x86/xen/setup.c')
-rw-r--r--arch/x86/xen/setup.c27
1 files changed, 27 insertions, 0 deletions
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 9efca750405d..740517be4da5 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -424,6 +424,33 @@ char * __init xen_memory_setup(void)
424 e820_add_region(ISA_START_ADDRESS, ISA_END_ADDRESS - ISA_START_ADDRESS, 424 e820_add_region(ISA_START_ADDRESS, ISA_END_ADDRESS - ISA_START_ADDRESS,
425 E820_RESERVED); 425 E820_RESERVED);
426 426
427 /*
428 * Reserve Xen bits:
429 * - mfn_list
430 * - xen_start_info
431 * See comment above "struct start_info" in <xen/interface/xen.h>
432 * We tried to make the the memblock_reserve more selective so
433 * that it would be clear what region is reserved. Sadly we ran
434 * in the problem wherein on a 64-bit hypervisor with a 32-bit
435 * initial domain, the pt_base has the cr3 value which is not
436 * neccessarily where the pagetable starts! As Jan put it: "
437 * Actually, the adjustment turns out to be correct: The page
438 * tables for a 32-on-64 dom0 get allocated in the order "first L1",
439 * "first L2", "first L3", so the offset to the page table base is
440 * indeed 2. When reading xen/include/public/xen.h's comment
441 * very strictly, this is not a violation (since there nothing is said
442 * that the first thing in the page table space is pointed to by
443 * pt_base; I admit that this seems to be implied though, namely
444 * do I think that it is implied that the page table space is the
445 * range [pt_base, pt_base + nt_pt_frames), whereas that
446 * range here indeed is [pt_base - 2, pt_base - 2 + nt_pt_frames),
447 * which - without a priori knowledge - the kernel would have
448 * difficulty to figure out)." - so lets just fall back to the
449 * easy way and reserve the whole region.
450 */
451 memblock_reserve(__pa(xen_start_info->mfn_list),
452 xen_start_info->pt_base - xen_start_info->mfn_list);
453
427 sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); 454 sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
428 455
429 return "Xen"; 456 return "Xen";