While adding code to create the compatibility p2m table mappings it seemed to me that the creation of the native ones is restricted to memory below the 512G boundary - otherwise, additional L2 tables would need to be allocated (currently other memory following the one L2 page getting allocated would be blindly overwritten). While I realize that machines this big aren''t likely to be targeted by Xen at this point anyway (although the direct map area explicitly provides for 1T), I''d still want this fixed if someone confirms I''m not mis-reading something here (of if that''s the case, then I''d still need a good explanation, as then I''m likely screwing up the compatibility table creation). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Correct. I suggest either a clean BUG_ON() in virt_to_xen_l2e(), or allocate-and-map the new l2 in that same function (but raises question of how to test the new code path). -- Keir On 31/8/06 10:34 am, "Jan Beulich" <jbeulich@novell.com> wrote:> While adding code to create the compatibility p2m table mappings it > seemed > to me that the creation of the native ones is restricted to memory below > the 512G boundary - otherwise, additional L2 tables would need to be > allocated (currently other memory following the one L2 page getting > allocated would be blindly overwritten). While I realize that machines > this > big aren''t likely to be targeted by Xen at this point anyway (although > the > direct map area explicitly provides for 1T), I''d still want this fixed > if > someone confirms I''m not mis-reading something here (of if that''s the > case, > then I''d still need a good explanation, as then I''m likely screwing up > the > compatibility table creation)._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 31.08.06 19:58 >>> >Correct. I suggest either a clean BUG_ON() in virt_to_xen_l2e(), or >allocate-and-map the new l2 in that same function (but raises question of >how to test the new code path).Why in virt_to_xen_l2e()? We likely wouldn''t make it there on a system this big, due to earlier memory corruption. But anyway, I''ll try to change the code so the code path won''t be entirely unused (similar to the dom0 page table setup in contruct_dom0()). Jan>On 31/8/06 10:34 am, "Jan Beulich" <jbeulich@novell.com> wrote: > >> While adding code to create the compatibility p2m table mappings it >> seemed >> to me that the creation of the native ones is restricted to memory below >> the 512G boundary - otherwise, additional L2 tables would need to be >> allocated (currently other memory following the one L2 page getting >> allocated would be blindly overwritten). While I realize that machines >> this >> big aren''t likely to be targeted by Xen at this point anyway (although >> the >> direct map area explicitly provides for 1T), I''d still want this fixed >> if >> someone confirms I''m not mis-reading something here (of if that''s the >> case, >> then I''d still need a good explanation, as then I''m likely screwing up >> the >> compatibility table creation)._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 1/9/06 4:38 pm, "Jan Beulich" <jbeulich@novell.com> wrote:>> Correct. I suggest either a clean BUG_ON() in virt_to_xen_l2e(), or >> allocate-and-map the new l2 in that same function (but raises question of >> how to test the new code path). > > Why in virt_to_xen_l2e()? We likely wouldn''t make it there on a system > this big, due to earlier memory corruption.Why? The memory is only discovered and mapped after the e820 map is parsed. The mapping occurs via map_pages_to_xen(). That function discovers the l2e by using virt_to_xen_l2e(). So I think it ought to work. You can test it out by doing a map_pages_to_xen() call on an area of virtual address space that currently has no l2e. Should crash now, and work with the modified virt_to_xen_l2e(). -- Keir> But anyway, I''ll try to change the code so the code path won''t be entirely > unused (similar to the dom0 page table setup in contruct_dom0())._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 1/9/06 4:49 pm, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> wrote:>>> Correct. I suggest either a clean BUG_ON() in virt_to_xen_l2e(), or >>> allocate-and-map the new l2 in that same function (but raises question of >>> how to test the new code path). >> >> Why in virt_to_xen_l2e()? We likely wouldn''t make it there on a system >> this big, due to earlier memory corruption. > > Why? The memory is only discovered and mapped after the e820 map is parsed. > The mapping occurs via map_pages_to_xen(). That function discovers the l2e > by using virt_to_xen_l2e(). So I think it ought to work. > > You can test it out by doing a map_pages_to_xen() call on an area of virtual > address space that currently has no l2e. Should crash now, and work with the > modified virt_to_xen_l2e().Actually virt_to_xen_l2e() already allocates pagetables on demand, it turns out. So I think there is no issue here that needs fixing. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 01.09.06 17:58 >>> >On 1/9/06 4:49 pm, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> wrote: > >>>> Correct. I suggest either a clean BUG_ON() in virt_to_xen_l2e(), or >>>> allocate-and-map the new l2 in that same function (but raises question of >>>> how to test the new code path). >>> >>> Why in virt_to_xen_l2e()? We likely wouldn''t make it there on a system >>> this big, due to earlier memory corruption. >> >> Why? The memory is only discovered and mapped after the e820 map is parsed. >> The mapping occurs via map_pages_to_xen(). That function discovers the l2e >> by using virt_to_xen_l2e(). So I think it ought to work. >> >> You can test it out by doing a map_pages_to_xen() call on an area of virtual >> address space that currently has no l2e. Should crash now, and work with the >> modified virt_to_xen_l2e(). > >Actually virt_to_xen_l2e() already allocates pagetables on demand, it turns >out. So I think there is no issue here that needs fixing.Here''s the change I was hinting towards - replaces the BUG_ON() with proper code. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2006-09-11/xen/arch/x86/x86_64/mm.c ==================================================================--- 2006-09-11.orig/xen/arch/x86/x86_64/mm.c 2006-09-12 10:39:39.000000000 +0200 +++ 2006-09-11/xen/arch/x86/x86_64/mm.c 2006-09-12 10:41:24.000000000 +0200 @@ -78,7 +78,7 @@ void __init paging_init(void) { unsigned long i, mpt_size; l3_pgentry_t *l3_ro_mpt; - l2_pgentry_t *l2_ro_mpt; + l2_pgentry_t *l2_ro_mpt = NULL; struct page_info *pg; /* Create user-accessible L2 directory to map the MPT for guests. */ @@ -87,12 +87,6 @@ void __init paging_init(void) idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)] l4e_from_page( virt_to_page(l3_ro_mpt), __PAGE_HYPERVISOR | _PAGE_USER); - l2_ro_mpt = alloc_xenheap_page(); - clear_page(l2_ro_mpt); - l3_ro_mpt[l3_table_offset(RO_MPT_VIRT_START)] - l3e_from_page( - virt_to_page(l2_ro_mpt), __PAGE_HYPERVISOR | _PAGE_USER); - l2_ro_mpt += l2_table_offset(RO_MPT_VIRT_START); /* * Allocate and map the machine-to-phys table. @@ -110,10 +104,20 @@ void __init paging_init(void) PAGE_HYPERVISOR); memset((void *)(RDWR_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT)), 0x55, 1UL << L2_PAGETABLE_SHIFT); + if ( !((unsigned long)l2_ro_mpt & ~PAGE_MASK) ) + { + unsigned long va = RO_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT); + + l2_ro_mpt = alloc_xenheap_page(); + clear_page(l2_ro_mpt); + l3_ro_mpt[l3_table_offset(va)] + l3e_from_page( + virt_to_page(l2_ro_mpt), __PAGE_HYPERVISOR | _PAGE_USER); + l2_ro_mpt += l2_table_offset(va); + } /* NB. Cannot be GLOBAL as shadow_mode_translate reuses this area. */ *l2_ro_mpt++ = l2e_from_page( pg, /*_PAGE_GLOBAL|*/_PAGE_PSE|_PAGE_USER|_PAGE_PRESENT); - BUG_ON(((unsigned long)l2_ro_mpt & ~PAGE_MASK) == 0); } /* Set up linear page table mapping. */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Seemingly Similar Threads
- [PATCH 1/1] Xen PV support for hugepages
- [PATCH 0 of 4] Use superpages on restore/migrate
- help interpreting output?
- Walking an HVM''s shadow page tables and other memory management questions.
- [PATCH 0 of 4 RFC] Populate-on-demand: Check pages being returned by the balloon driver