Xen devel - May 2006 - [PATCH] x86-64 linux: unmap temporary mappings established for setup of 1:1 mappings

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).

Also some minor cleanup.

Signed-off-by: Jan Beulich <jbeulich@novell.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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?

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.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 1 Jun 2006, at 19:21, Keir Fraser 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?
Might it make sense to zap all init mappings (after kernel code/data) 
in mem_init(), where we leave ''bootmem mode''? At that point
initrd etc.
can all be accessed via the main 1:1 mapping. I think this should work 
so long as we don''t have any residual pointers to the init mapping 
hanging around.

Another concern I have is that our x86/64 mm/init.c is still very 
complicated and rather different from native mm/init.c (even though I 
did clean it up a lot some time ago). I''m interested in any ideas about
how to reduce the complexity...

  -- 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.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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 2 Jun 2006, at 08:29, Jan Beulich wrote:
>> 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?
Ah yes. Well, given that things like the console and xenbus pages are 
also above the initrd mapping, they must also be dealt with to properly 
be sure of a clear section of address space for modules.

I backed out the patch in -unstable since it didn''t build. In any case 
I felt that it was doing more than just zapping the extra init mappings 
(it changed various bits and pieces, I think to allow safe calling of 
init_memory_mapping() after bootstrap, which I think we never currently 
do -- it belongs in a separate patch anyway).

I think I will wait until someone has a chance to look at this more 
thoroughly and can make a patch that zaps all the init mappings in one 
single place. I''ll then look at backporting that patch to -testing.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>I backed out the patch in -unstable since it didn''t build. In any
case
>I felt that it was doing more than just zapping the extra init mappings 
>(it changed various bits and pieces, I think to allow safe calling of 
>init_memory_mapping() after bootstrap, which I think we never currently 
>do -- it belongs in a separate patch anyway).
>
>I think I will wait until someone has a chance to look at this more 
>thoroughly and can make a patch that zaps all the init mappings in one 
>single place. I''ll then look at backporting that patch to -testing.
While I saw that the essential part of the patch was applied (again), here is a
patch to remove all early mappings
(except for the kernel image itself, of course).

Signed-off-by: Jan Beulich <jbeulich@novell.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel