linux-mips
[Top] [All Lists]

Re: get_mmu_context()

To: linux-mips@fnet.fr
Subject: Re: get_mmu_context()
From: Harald Koerfgen <harald.koerfgen@netcologne.de>
Date: Wed, 21 Oct 1998 21:31:40 +0200 (MEST)
Cc: Vladimir Roganov <roganov@niisi.msk.ru>, linux@cthulhu.engr.sgi.com
In-reply-to: <19981019121804.F387@uni-koblenz.de>
Organization: none
Reply-to: "Harald Koerfgen" <harald.koerfgen@netcologne.de>
Sender: owner-linux@cthulhu.engr.sgi.com
On 19-Oct-98 ralf@uni-koblenz.de wrote:
> On Sun, Oct 18, 1998 at 09:53:18PM +0200, Harald Koerfgen wrote:

[...]
> There is a number of machines, most popular some DECstation, which are
> available with both CPU architectures.

Yup.
 
> The other location for which patching might be useful are primarily the
> differences between the R3000 and R4000 status register, especially the
> KU rsp. KSU bits.  What other places do you have in mind?

Agreed. There are indeed other places where code could be reintegrated,
r2300_switch.S and r4k_switch.S come to mind.

On the other hand, there is code which should be seperated for performance 
reasons,
mainly the RESTORE_ALL macros thus affecting entry.S and scall_o32.S. Actually 
these
problems are solved by conditional compiling.
 
>> To make those changes generic needs either a reasonable amount of hacking or
>> avoidable code duplication. In fact, if we really don't care about self
>> modifying code we should be able to remove some code duplication, for
>> example in the fpu stuff.
> 
> People should consider that we'll be able to hide the self modifications
> in C code very nicely.  I would not go for anything which I consider a
> maintenance problem or major uglyness.

Good.
 
> Let me explain how the approach from my recent patch works:

[explanation snipped]
 
> Todo: we don't want a separate section per patched instruction.  Easy to
> fix.  We also want to get rid of the special section just like other
> initfunc stuff.

That sounds great. We could even put all ISA dependant code into seperate
sections and get rid of all the ISA sections, which aren't needed.
 
> The next class of things to patch are the zillion of function calls using
> function pointers.  We can insert a jal instruction and patch it's
> destination address.  Candidates for that include calls to flush_cache_all,
> flush_cache_mm, flush_cache_range, flush_cache_page, flush_cache_sigtramp,
> flush_tlb_all, flush_tlb_mm, flush_tlb_range, flush_tlb_page, add_wired_entry,
> clear_page, copy_page.
> 
> Both parts, patching immediate opperands and function calls can be dealt
> with similar to the approach in the userland dynamic linker, that initially
> the function called is the dynamic linker's kernel equivalent which will
> choose the right thing to do.
> 
> Extra goodie for the R3000 fraction: Many functions called via above
> mentioned pointers are empty, calls to them may be eleminated by overwriting
> the calling jal with nops.  Say goodbye to another hand full of cycles.

That sounds even better :-).
---
Regards,
Harald

<Prev in Thread] Current Thread [Next in Thread>