Jan Beulich
2012-Sep-03 06:58 UTC
[PATCH] x86/32-on-64: adjust Dom0 initial page table layout
Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and
allocate its L3 first (to match behavior when running identical bit-
width hypervisor and Dom0 kernel).
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -510,7 +510,7 @@ int __init construct_dom0(
#define NR(_l,_h,_s) \
(((((_h) + ((1UL<<(_s))-1)) & ~((1UL<<(_s))-1)) - \
((_l) & ~((1UL<<(_s))-1))) >> (_s))
- if ( (1 + /* # L4 */
+ if ( (!is_pv_32on64_domain(d) + /* # L4 */
NR(v_start, v_end, L4_PAGETABLE_SHIFT) + /* # L3 */
(!is_pv_32on64_domain(d) ?
NR(v_start, v_end, L3_PAGETABLE_SHIFT) : /* # L2 */
@@ -756,6 +756,8 @@ int __init construct_dom0(
panic("Not enough RAM for domain 0 PML4.\n");
page->u.inuse.type_info = PGT_l4_page_table|PGT_validated|1;
l4start = l4tab = page_to_virt(page);
+ maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l3_page_table;
+ l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
}
copy_page(l4tab, idle_pg_table);
l4tab[0] = l4e_empty(); /* zap trampoline mapping */
@@ -787,9 +789,13 @@ int __init construct_dom0(
l2tab += l2_table_offset(v_start);
if ( !((unsigned long)l3tab & (PAGE_SIZE-1)) )
{
- maddr_to_page(mpt_alloc)->u.inuse.type_info -
PGT_l3_page_table;
- l3start = l3tab = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+ if ( count || !l3start )
+ {
+ maddr_to_page(mpt_alloc)->u.inuse.type_info +
PGT_l3_page_table;
+ l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+ }
+ l3tab = l3start;
clear_page(l3tab);
if ( count == 0 )
l3tab += l3_table_offset(v_start);
@@ -938,7 +944,7 @@ int __init construct_dom0(
if ( !vinitrd_start && initrd_len )
si->flags |= SIF_MOD_START_PFN;
si->flags |= (xen_processor_pmbits << 8) & SIF_PM_MASK;
- si->pt_base = vpt_start + 2 * PAGE_SIZE * !!is_pv_32on64_domain(d);
+ si->pt_base = vpt_start;
si->nr_pt_frames = nr_pt_pages;
si->mfn_list = vphysmap_start;
snprintf(si->magic, sizeof(si->magic), "xen-3.0-x86_%d%s",
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Keir Fraser
2012-Sep-03 07:38 UTC
Re: [PATCH] x86/32-on-64: adjust Dom0 initial page table layout
On 03/09/2012 07:58, "Jan Beulich" <JBeulich@suse.com> wrote:> Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and > allocate its L3 first (to match behavior when running identical bit- > width hypervisor and Dom0 kernel). > > Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > Signed-off-by: Jan Beulich <jbeulich@suse.com>This, and your other proposed patch to xc_dom_x86.c, I''m not sure about for 4.2.0. Are we prepared to possibly slip 4.2.0 for these, rather than put them in 4.2.1 instead (which will certainly be sooner than our proposed usual 3-month schedule for point releases)? -- Keir> --- a/xen/arch/x86/domain_build.c > +++ b/xen/arch/x86/domain_build.c > @@ -510,7 +510,7 @@ int __init construct_dom0( > #define NR(_l,_h,_s) \ > (((((_h) + ((1UL<<(_s))-1)) & ~((1UL<<(_s))-1)) - \ > ((_l) & ~((1UL<<(_s))-1))) >> (_s)) > - if ( (1 + /* # L4 */ > + if ( (!is_pv_32on64_domain(d) + /* # L4 */ > NR(v_start, v_end, L4_PAGETABLE_SHIFT) + /* # L3 */ > (!is_pv_32on64_domain(d) ? > NR(v_start, v_end, L3_PAGETABLE_SHIFT) : /* # L2 */ > @@ -756,6 +756,8 @@ int __init construct_dom0( > panic("Not enough RAM for domain 0 PML4.\n"); > page->u.inuse.type_info = PGT_l4_page_table|PGT_validated|1; > l4start = l4tab = page_to_virt(page); > + maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l3_page_table; > + l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE; > } > copy_page(l4tab, idle_pg_table); > l4tab[0] = l4e_empty(); /* zap trampoline mapping */ > @@ -787,9 +789,13 @@ int __init construct_dom0( > l2tab += l2_table_offset(v_start); > if ( !((unsigned long)l3tab & (PAGE_SIZE-1)) ) > { > - maddr_to_page(mpt_alloc)->u.inuse.type_info > - PGT_l3_page_table; > - l3start = l3tab = __va(mpt_alloc); mpt_alloc +> PAGE_SIZE; > + if ( count || !l3start ) > + { > + maddr_to_page(mpt_alloc)->u.inuse.type_info > + PGT_l3_page_table; > + l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE; > + } > + l3tab = l3start; > clear_page(l3tab); > if ( count == 0 ) > l3tab += l3_table_offset(v_start); > @@ -938,7 +944,7 @@ int __init construct_dom0( > if ( !vinitrd_start && initrd_len ) > si->flags |= SIF_MOD_START_PFN; > si->flags |= (xen_processor_pmbits << 8) & SIF_PM_MASK; > - si->pt_base = vpt_start + 2 * PAGE_SIZE * !!is_pv_32on64_domain(d); > + si->pt_base = vpt_start; > si->nr_pt_frames = nr_pt_pages; > si->mfn_list = vphysmap_start; > snprintf(si->magic, sizeof(si->magic), "xen-3.0-x86_%d%s", > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Jan Beulich
2012-Sep-03 07:57 UTC
Re: [PATCH] x86/32-on-64: adjust Dom0 initial page table layout
>>> On 03.09.12 at 09:38, Keir Fraser <keir.xen@gmail.com> wrote: > On 03/09/2012 07:58, "Jan Beulich" <JBeulich@suse.com> wrote: > >> Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and >> allocate its L3 first (to match behavior when running identical bit- >> width hypervisor and Dom0 kernel). >> >> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> > > This, and your other proposed patch to xc_dom_x86.c, I''m not sure about for > 4.2.0. Are we prepared to possibly slip 4.2.0 for these, rather than put > them in 4.2.1 instead (which will certainly be sooner than our proposed > usual 3-month schedule for point releases)?Holding back this one for post-4.2 is fine with me (as it doesn''t really address an outright bug, it just makes things more consistent). The tools side patch, however, I consider more important, since the code is so obviously flawed (and that''s irrespective of this having been that way all the way back to the introduction of the "new" [back then] domain builder). But of course I''d like to see it tested with that big a domain first, which I can''t due to not having access to a suitable system. Jan