TASK_SIZE default 0x80000000 ?

TASK_SIZE default 0x80000000 ?

[Kumar Gala]

In a discussion with Hollis over beer he raised the question why  
TASK_SIZE is 0x80000000 on ppc32.

I was wondering if anyone know why this was still the case?  Seems  
like we have a 1Gb whole between TASK_SIZE & KERNELBASE.

- k

Re: TASK_SIZE default 0x80000000 ?

[Dan Malek]

On Oct 6, 2007, at 6:36 AM, Kumar Gala wrote:

> In a discussion with Hollis over beer he raised the question why
> TASK_SIZE is 0x80000000 on ppc32.

Left over from the old days (2.1) of the PReP port when
things were hard coded.  We used some of the space
between 0x80000000 and 0xc0000000 for mapping
IO devices in the kernel.

> I was wondering if anyone know why this was still the case?  Seems
> like we have a 1Gb whole between TASK_SIZE & KERNELBASE.

I thought all of this was now configurable in the
advanced options.  The configuration files should
set the default to remove this gap.

	-- Dan

Re: TASK_SIZE default 0x80000000 ?

[Paul Mackerras]

Kumar Gala writes:

> In a discussion with Hollis over beer he raised the question why  
> TASK_SIZE is 0x80000000 on ppc32.
> 
> I was wondering if anyone know why this was still the case?  Seems  
> like we have a 1Gb whole between TASK_SIZE & KERNELBASE.

Two reasons: (a) PReP used to map PCI stuff with BATs in the
0x80000000 - 0xbfffffff region, and (b) some embedded ports with
software-loaded TLBs test just the high bit of the address to
determine whether to use the kernel or user page tables.

Paul.

Re: TASK_SIZE default 0x80000000 ?

[Kumar Gala]

On Oct 6, 2007, at 11:06 PM, Paul Mackerras wrote:

> Kumar Gala writes:
>
>> In a discussion with Hollis over beer he raised the question why
>> TASK_SIZE is 0x80000000 on ppc32.
>>
>> I was wondering if anyone know why this was still the case?  Seems
>> like we have a 1Gb whole between TASK_SIZE & KERNELBASE.
>
> Two reasons: (a) PReP used to map PCI stuff with BATs in the
> 0x80000000 - 0xbfffffff region, and (b) some embedded ports with
> software-loaded TLBs test just the high bit of the address to
> determine whether to use the kernel or user page tables.

Can you explain (a) further -- I'm assuming the BAT mapping is 1:1  
for that region?

For (b) it looks like:
* 40x, 44x, fsl-booke compare against TASK_SIZE in their software  
handlers.
* 8xx still tests 0x80000000
* 6xx (603) compares against KERNELBASE

It would seem like we should set the default on 8xx & PReP to  
0x80000000 and not allow it to be modified since that will break the  
world and for everything else move it to match KERNELBASE.  Any  
issues with that?

- k

Re: TASK_SIZE default 0x80000000 ?

[Dan Malek]

On Oct 7, 2007, at 8:02 AM, Kumar Gala wrote:

> It would seem like we should set the default on 8xx & PReP to
> 0x80000000 and not allow it to be modified

For as much as this has been discussed in the past,
I don't know why the 8xx doesn't check KERNEL_BASE
and work properly with the options.  There is no reason
this can't work.  The history is I wrote the tlb handlers
to test the MS bit due to a hardcoded address, not that
the address is hardcoded because I wanted to just
test a bit.  Unlike PReP, there is no reason to
disallow modification, if this test was changed.

Thanks.

	-- Dan

Re: TASK_SIZE default 0x80000000 ?

[Kumar Gala]

On Oct 7, 2007, at 1:35 PM, Dan Malek wrote:

>
> On Oct 7, 2007, at 8:02 AM, Kumar Gala wrote:
>
>> It would seem like we should set the default on 8xx & PReP to
>> 0x80000000 and not allow it to be modified
>
> For as much as this has been discussed in the past,
> I don't know why the 8xx doesn't check KERNEL_BASE
> and work properly with the options.  There is no reason
> this can't work.  The history is I wrote the tlb handlers
> to test the MS bit due to a hardcoded address, not that
> the address is hardcoded because I wanted to just
> test a bit.  Unlike PReP, there is no reason to
> disallow modification, if this test was changed.

Ok, I'll work up a patch for 8xx to test against PAGE_OFFSET (as benh  
suggested).

- k

Re: TASK_SIZE default 0x80000000 ?

[Benjamin Herrenschmidt]

> Can you explain (a) further -- I'm assuming the BAT mapping is 1:1  
> for that region?
> 
> For (b) it looks like:
> * 40x, 44x, fsl-booke compare against TASK_SIZE in their software  
> handlers.
> * 8xx still tests 0x80000000
> * 6xx (603) compares against KERNELBASE
> 
> It would seem like we should set the default on 8xx & PReP to  
> 0x80000000 and not allow it to be modified since that will break the  
> world and for everything else move it to match KERNELBASE.  Any  
> issues with that?

The proper value is neither :-)

It should be compared against PAGE_OFFSET.

Ben.

Re: TASK_SIZE default 0x80000000 ?

[Kumar Gala]

On Oct 7, 2007, at 4:05 PM, Benjamin Herrenschmidt wrote:

>
>> Can you explain (a) further -- I'm assuming the BAT mapping is 1:1
>> for that region?
>>
>> For (b) it looks like:
>> * 40x, 44x, fsl-booke compare against TASK_SIZE in their software
>> handlers.
>> * 8xx still tests 0x80000000
>> * 6xx (603) compares against KERNELBASE
>>
>> It would seem like we should set the default on 8xx & PReP to
>> 0x80000000 and not allow it to be modified since that will break the
>> world and for everything else move it to match KERNELBASE.  Any
>> issues with that?
>
> The proper value is neither :-)
>
> It should be compared against PAGE_OFFSET.

I'll work up a patch to switch us to testing PAGE_OFFSET instead.

- k