[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86-64 linux: unmap temporary mappings established for setup of 1:1 mappings
>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 01.06.06 20:21 >>> > >On 31 May 2006, at 14:17, Jan Beulich wrote: > >> The temporary mappings needed to set up the 1:1 mappings must be torn >> down after use; otherwise they may trigger the >> WARN_ON() in vmap_pte_range() (namely if the chunk allocated to hold >> kernel and initial page tables gets close to or >> exceeds 128Mb, or if a sufficiently high mem= argument causes the >> static allocations to grow beyond 128Mb, which in >> either case means these mappings extend into the modules area). > >I've applied this to -unstable, but in this patch I only see code to >destroy the extended init mappings. What happens if you have a really >big initrd (for example)? That will push the initial pagetables up into >the modules area -- is that handled correctly now or is more fixup >required? The initrd mappings, as I read it, get destroyed in setup_arch(). The thing that also came to my mind were the Xen-created page tables, which might need taking care of. The main issue here will be to precisely determine the boundary of where to start destruction - does Xen make any guarantees regarding the ordering of things within the initial allocation? >Also your patch didn't apply to 3.0-testing. You'll need to supply a >version specifically for -testing if you want it applied there. Yes, that patch would look different. As we have our own patch anyway, I don't think we insist on this being applied to 3.0-testing, but in case you want it I'm attaching the patch we have (one of its hunks applies with fuzz 1 only, but I think that should be okay). Jan Attachment:
xen-x86_64-unmap-early.patch _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |