603 support

Benjamin Herrenschmidt mol-devel@lists.maconlinux.org
Thu, 2 May 2002 20:35:27 +0200


>
>Yes. But taking the has lock requires MOL support in the
>kernel proper. To be backward compatible we could optionally use
>a private 64K page table. It doesn't require many lines of
>code to implement...

Why would you need to be in the kernel ?

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

Beware also that the linux PTE will be possibly in highmem
on 2.5... 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

>> though I'm not sure what MOL does regarding linux PTEs (do you
>> touch them at all ?).
>
>No. Well, MOL might overwrite PTEs at PTEG overflow but that 
>is all.

What do you mean by overwrite PTEs at PTEG overflow ? you mean
evicting hash PTE entries ? That's not an issue if protected
by the hash lock. No, I was talking about the linux PTEs, that
is the PTEs of the linux page tables, not the hash table.

>> The VM somewhat relies on us properly
>> setting PAGE_ACCESSED when putting things in the hash table on
>> fault, and PAGE_HASHPTE should be set for a page that may be
>> in the hash or the kernel flush code would fail to flush the
>> page, but I beleive you have already that working.
>
>Yes, that should be fully working.

Ok.

Ben.