lkml.org 
[lkml]   [2003]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Fastboot] Re: Kexec on 2.5.59 problems ?
Here's the explanation from Anton about why using init_mm is
a problem on ppc64.

Regards
Suparna

----- Forwarded message from Anton Blanchard <anton@samba.org> -----

Date: Tue, 18 Feb 2003 20:56:23 +1100
From: Anton Blanchard <anton@samba.org>
To: Suparna Bhattacharya <suparna@in.ibm.com>
Subject: Re: Fw: Re: [Fastboot] Re: Kexec on 2.5.59 problems ?


On Thu, Feb 13, 2003 at 08:10:41AM -0700, Eric W. Biederman wrote:
> Suparna Bhattacharya <suparna@in.ibm.com> writes:
>
> > Great !
> > Eventually we should probably avoid init_mm altogether (on ppc64
> > at least, init_mm can't be used as Anton pointed out to me) and
> > setup a spare mm instead.
>
> What is the problem with init_mm? Besides the fact that using it
> is now failing?
>


Hi Suparna,

On ppc64 we have many 2^41B (2 TB) regions:

USER
KERNEL
VMALLOC
IO

Why 2TB? Well our three level linux pagetables can map 2TB. The kernel has
no pagetables, so we only need three sets of pagetables. As usual each
user task has its own set of pagetables. So that leaves vmalloc and IO.

For IO we create our own pgd, ioremap_pgd and for vmalloc we use init_mm.
Why not? Its not being used anywhere else... except for kexec.

So init_mm covers the region of:

0xD000000000000000 to 0xD000000000000000+2^41

And what kexec wants is a page under 4GB :)

Thats why we created another mm.


Could you please forward it on to the list?

Thanks!
Anton

----- End forwarded message -----

--
Suparna Bhattacharya (suparna@in.ibm.com)
Linux Technology Center
IBM Software Labs, India
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.183 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site