603 support

[Greg Alexander]

samuel@ibrium.se wrote:
> 
> On Wed, May 01, 2002 at 12:45:44PM -0500, Greg Alexander wrote:
> > 1.) Is there still a way to get the current MOL working with a 2.2.20
> > kernel?  i.e. when did linux stop using page tables on the 603?
> >
> Hmm... I think it ought to work. The 603 code is present
> in recent 2.2 kernels (but disabled by default). Change
> 
>         #define NO_RELOAD_HTAB  1
> 
> to zero in arch/ppc/kernel/head.S and arch/ppc/mm/init.c
> in order to activate it. To get mol running, you will
> have to disable the 603 hooks (and the SDR1 manipulation).

I'm not clear on what all would be involved with getting it to work with
an old kernel.

Specifically:

1.) What changes do I need to make to the old kernel?  Just changing
this single #define and using the module, or do I need to do other
things to patch it too?
2.) Is it just the page table initialization that I have to change, or
is it some other stuff too?


> > 2.) The 603 problems seem to be related to telling linux that we've got
> > a 603... why not tell it we're running a sort of 604 in a kernel patch?
> > Then wouldn't it use "real" page tables?
> 
> More or less, but the exception handlers for the 603 traps
> are needed (those that are in the 2.2 kernel).

Right.  As noted before, these problems seem to be minor.

> > 3.) If not #2, what do we currently try to do to get around the kernel
> > not using PPC page tables?
> >
> > It looks to me like we build our own hash table, correct?
> 
> Yes. Essentially MOL contains the code that used to be in
> the 2.2 kernels.

I hate to do this, but I think I'm going to have to because I'm having
trouble figuring things out myself...

How exactly do we take care of:
1.) updating the host linux R/C bits (or equivalent)?
2.) updating the guest R/C bits?

It seems like these may be the problem, as they would be handled
differently between a shared and an unshared hash table, and I don't see
how we're updating the linux changed bit when we do the hash table walk
on an unset C bit write.  Of course, I'm probably missing something, as
I'm not clear on how the 603 vectors get linked up with everything else.

> > How do we ensure that this is kept in sync with what's really in memory?
> 
> The same way as on non-603 machines. MOL uses a hook to detect
> page table flushes. If a page used by MOL is affected, it
> is flushed from the hash table and and TLB cache.
> 
> > 4.) Do we really need to use SDR1? (not that I suspect this is the
> > problem, but it's worth looking into.)  Actually, the SDR1 code looks a
> > little suspiscious to me.  I'm going to look at it some more.
> 
> The benefit of using SDR1 is that the hardware computes certain
> things before the 603 exception is taken. It is not *necessary*
> to use SDR1, but it simplifies things. And since the kernel
> doesn't use it...

Right.  If the kernel really doesn't use it, we're fine.  I was just
wondering if that was really an okay assumption.  I guess it is.

GREG