[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/xen: Fix 64bit kernel pagetable setup of PV guests
On 29/08/14 16:17, Stefan Bader wrote: > > This change might not be the fully correct approach as it basically > removes the pre-set page table entry for the fixmap that is compile > time set (level2_fixmap_pgt[506]->level1_fixmap_pgt). For one the > level1 page table is not yet declared in C headers (that might be > fixed). But also with the current bug, it was removed, too. Since > the Xen mappings for level2_kernel_pgt only covered kernel + initrd > and some Xen data this did never reach that far. And still, something > does create entries at level2_fixmap_pgt[506..507]. So it should be > ok. At least I was able to successfully boot a kernel with 1G kernel > image size without any vmalloc whinings. [...] > --- a/arch/x86/xen/mmu.c > +++ b/arch/x86/xen/mmu.c > @@ -1902,8 +1902,22 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, > unsigned long max_pfn) > /* L3_i[0] -> level2_ident_pgt */ > convert_pfn_mfn(level3_ident_pgt); > /* L3_k[510] -> level2_kernel_pgt > - * L3_i[511] -> level2_fixmap_pgt */ > + * L3_k[511] -> level2_fixmap_pgt */ > convert_pfn_mfn(level3_kernel_pgt); > + > + /* level2_fixmap_pgt contains a single entry for the > + * fixmap area at offset 506. The correct way would > + * be to convert level2_fixmap_pgt to mfn and set the > + * level1_fixmap_pgt (which is completely empty) to RO, > + * too. But currently this page table is not declared, > + * so it would be a bit of voodoo to get its address. > + * And also the fixmap entry was never set due to using > + * the wrong l2 when getting Xen's tables. So let's just > + * just nuke it. > + * This orphans level1_fixmap_pgt, but that was basically > + * done before the change as well. > + */ > + memset(level2_fixmap_pgt, 0, 512*sizeof(long)); level2_fixmap_pgt etc. are defined for the benefit of Xen only so I think you should add an extern for level1_fixmap_pgt and fix this up properly. It might not matter now, but it might in the future... David _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |