603 support

[mol-devel@lists.maconlinux.org]

On Thu, May 02, 2002 at 05:10:24PM -0500, Greg Alexander wrote:
> 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?

No, changing the two #defines should be it, I think.

> 2.) Is it just the page table initialization that I have to change, or
> is it some other stuff too?

The page table stuff and the 603 exception hooks. The macro 
at the beginning of each vector contains the linking magic which tells
mol to patch the real exception vector, so simply commenting out
603.S ought to do it.

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

Actually, Linux doesn't use the R/C bits. This is one reason why
it is safe to overwrite Linux PTEs when a PTEG is full.
Linux implements what roughly corresponds to the R/C bits at the
linux page table level.

MOL uses the hash PTE R/C bits to track which framebuffer lines 
have been modified (in order to speed up the X11 video). The 
"emulated" MacOS R/C bits are implemented using exceptions. 
For instance, a MacOS page is originally read only. When there is 
a write to the page, the emulated MacOS R/C bits are updated from 
the exception handler (at the same time, the linux page table
entry is marked dirty).

I guess one could use the R/C bits further, but by the measurements
I've done, the performance impact does not motivate a change
in this area.

Thus, the R/C bit handling in the exception vectors are not really
needed except for the framebuffer acceleration. Indeed,
the 2.2 kernel did not implement the R/C bits. On the
603, mol flushed the PTEs from the frambuffer each VBL
in order to work around this issue.

> Of course, I'm probably missing something, as
> I'm not clear on how the 603 vectors get linked up with everything else.

Well, this is mostly hidden in the header files. Since kernel 
modules are not continuous in physical memory, MOL relocates the 
(assembly) code at startup. Moreover, the bulk of the code runs
with the MMU off so virtual addresses must be converted to physical
ones. A perl script is used at compile time to create a table 
containing the relocation information (reloc_table.h). 

Besides the relocation, mol uses certain "Action" symbols to do 
special things. For instance, 

	.long Action_VRET + 0x300

is substituted with an absolute branch to the assembly instruction 
which was overwritten (and relocated) when mol inserted its head 
patch of the exception vector 0x300.

Similarly,

	.long Action_RELOC_HOOK
	.long 0x300
	.long trampoline_size
	.long return_offs
	...the trampoline code goes here...

instructs MOL to copy the trampoline code to a lowmem
location and patch the 0x300 trap.

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

Well, I checked the kernel source to be sure that this was indeed
the case. I think it is OK.

Cheers,

/Samuel