603 support

[mol-devel@lists.maconlinux.org]

On Thu, May 02, 2002 at 08:35:27PM +0200, Benjamin Herrenschmidt wrote:
> >If we take the kernel lock, we must put the complete hash
> >table operation in the kernel (e.g. insert PTE) since the
> >code holding the lock must be BAT mapped in order to
> >avoid deadlocks.
> 
> Ah, I see. Well, there might be possible workarounds. I have
> to think a bit. The kernel is changing in this regard (see
> 2.5). The simple way consist of disabling translation, but
> that can be a bit tricky for MOL hash table manipulations,
> except if MOL move itself in a kmalloc'ed block, which is
> then guaranteed to be contiguous. 

Well, the low-level stuff already is in a kmalloc'ed, resident
block. Turning off the MMU for doing page table manipulation
is a possibility.

> That way, MOL can use
> either a home made BAT when tapping the hash or more easily
> run with translation disabled.
> 
> >But what do we really need the kernel lock for? Clearly
> >PTE insertions must be protected, but what about zeroing
> >hash table entries or issuing tlbies? I remember having
> >seen some comment that the lock is needed for tlbie's,
> >but I don't really see why that is.
> 
> Well... the fact is that on hash table CPUs, we never tlbie
> directly ;) We always go though the hash page routines. After
> thinking a bit more about it, I agree doing tlbie's without
> the lock should be harmless, provided you don't tlbie
> anything but MOL pages.

The tlbie instruction will flush kernel pages since it
does not decode the ea completely. MOL might also zero 
out a kernel PTE entry if a MOL PTE has been evicted 
previously.

However, taking a closer look at my 604e manual, it seems
like tlbies should be guarded by a lock:

"When a snooping 604e detects a TLB invalidate entry
on the bus, it accepts the operation only if no TLB invalidate
entry operation is beeing executed by this processor
and only if all processors on the bus accepts the operation
(ARTRY is not asserted)."

The question is what happens if two processors issue tlbies 
simultaneously? I guess the flush is either ignored
by the other processor or ARTRY asserted which I guess
could result in a deadlock situation since both processors 
are executing tlbies.

> Beware also that the linux PTE will be possibly in highmem
> on 2.5... 

I haven't looked at the highmem implementation for PPC, but I 
guess this involves these extra PTE bits the 7450 has.

> But since Paulus also changed the whole exception
> entry/exit code path (we don't save all registers any more,
> only volatile ones, the others get saved lazily on context
> switch), MOL will probably require some ground work for 2.5

MOL no longer makes any assumptions about the kernel implementation
of the exceptions, so this shouldn't be an issue. MOL only 
depend upon the page table format, the kernel usage of VSIDs 
and the page flushing hook.

> What do you mean by overwrite PTEs at PTEG overflow ? you mean
> evicting hash PTE entries?

Yes.

/Samuel