[PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries

[Dan Malek]

On May 6, 2005, at 7:05 PM, Marcelo Tosatti wrote:

> Do you have any practical example which you are certain is going
> to break?

Not at the moment, but that doesn't mean we shouldn't maintain
consistency for anyone that wants to do so.

> I dont remember any, and I dont think any software should be walking
> kernel pte's directly...

Anyone can call get_pteptr and should get the proper information.

> It is not possible to have the 8Mbyte pinned TLB and 4kb pagetables
> mapping the same kernel virtual addresses.

I know, but we don't do that.  Like I said, if the 8M pinned entry is
in the TLB, we don't get exceptions for this space and we don't look
up PTEs and replace them.

> You can't have both a 4kb page and a 8Mbyte page mapping the virtual
> address KERNELBASE + 0.
>
> Do you agree?

Yes, but that isn't what we are doing.  We can have the 8M page
mapping virtual address 0xc0000000 to 0x0000000, and also another
4k page, at say 0xd0000000 map the same 0x00000000 physical page.
There are many circumstances when we have a kernel VM address
and a user VM address map the same physical page.  This is also
what we do to get uncached VM addresses for DMA.

> Right - I'm talking about kernel virtual addresses: in this specific 
> case,
> we can't have more than one mapping for the first page at KERNELBASE.

You can't do that in any case for anything, and I'm confused why you
keep mentioning this :-)

> So you do agree that pte's should not be created for the first
> 8MBytes if CONFIG_PIN_TLB is set? :)

NO.  Just leave that code alone.  I don't understand why you think
doing this will have any effect on the system operation.  If you are
able to run a system without creating these tables, then the pinned
TLBs must be working.  If pinned TLBs weren't working, the kernel
would crash.

Thanks.


	-- Dan