PowerPC interrupt setup

[Joshua LeVasseur]

Hi Kay-Uwe,

Sorry about the slow response; super busy here.

> You recommend "enabling virtual addressing immediatly". Did I  
> understand it right, that you use virtual memory in kernel mode? Is  
> this only for protection or means this, the kernel memory is  
> vitual? There are other kernels using virtual memory in kernel mode?

Probably all kernels use virtual addressing in kernel mode.  If I  
remember correctly, the processor executes with degraded performance  
in physical mode, but maybe I'm thinking about other processor  
architectures.

We need virtual addressing for Pistachio, since the kernel algorithms  
rely on the virtual addresses.  For example, the TCBs are managed via  
virtual addresses, to help reduce the number of TCB validity checks  
on the fast path, and for fast TCB lookup.  Other features requiring  
virtual addressing: string copy (temporary mapping), UTCBs  
(contiguous area).



>
> My design doesn't have a kernel section in the tasks address space  
> (on 32 bit machines a task is 4GB). I agonise to solve some of the  
> problems with this design. In the case StringItems used to send  
> Msg's from one space to another (means copy the information in the  
> kernel) the message buffer on both sides can scattered and located  
> across page bounderies. Handling this seems easier if the kernel  
> has the same view to memory and pionters to memory regions  
> (buffers) but this destroy my approach of lockfreeness, because the  
> String Buffers in different tasks can by overlap or locate at the  
> same virtual adress. (The sendphase of StringItems should by  
> interruptable and at any time it should by possible to handle as  
> much as possible StrinItem sends in the same time.) Handling this  
> in kernel with the view of real memory avoid overlapping buffer  
> regions from different threads. Do you see the issue like I and is  
> there a solution I didn't see?

The solution is to invalidate the string copy mapping when the thread  
is preempted.  When the thread is resumed, you'll get a page fault on  
the string copy, and then you restore the mapping area.  PowerPC's  
segments are perfect for solving this problem, because of the address  
space IDs: you dedicate one segment to string copy; you copy the  
segment of the destination thread's target area into the dedicated  
segment; and then you can copy.  When preempting, and when finished,  
you invalidate the dedicated copy segment.


> As I see on the homepage, the kernel runs on a G3 (aka PPC750). So  
> you use the normal hardware table search?

Yes, I use the hardware's hashed page table.  Since the hashed page  
table is limited in size, I also maintain a master copy of the  
information in a set of forward-mapped page tables.  Perhaps the  
forward-mapped page tables are unnecessary in PowerPC; I need them in  
Pistachio to be compatible with the architecture-neutral code  
(mapping database).


Regards,
Josh



>
> Thanks for helping.
>
> Regards
>
> Kay-Uwe.
>
> Am 07.02.2006 um 17:35 schrieb Joshua LeVasseur:
>
>>
>> The PowerPC jumps to predefined code locations when delivering  
>> interrupts and traps, starting at 0x100 (with virtual addressing  
>> disabled).  You only need to install code at those locations;  
>> PowerPC has no interrupt descriptors.  I recommend enabling  
>> virtual addressing immediately, even while handling page faults;  
>> I've seen other kernels implement excessive logic in assembler,  
>> executing in physical mode; that isn't necessary.  I enable  
>> virtual addressing within 19 or so instructions.
>>
>> Maybe try volume 3 here:
>> http://www-128.ibm.com/developerworks/eserver/articles/archguide.html
>> I've never read those documents; I used the 603 architecture  
>> manual when porting L4Ka::Pistachio.
>>
>> Consider reading about how I made my L4Ka::Pistachio PowerPC  
>> implementation frigging fast:
>> http://l4ka.org/projects/pistachio/powerpc/ppc.pdf
>> It covers:
>> - Fast system calls (without wasting a register for a system call  
>> number, unlike all other kernels out there that I've seen)
>> - Fast address space ID management (the way ASIDs were meant to be  
>> managed on the PowerPC, and again, the other kernels out there are  
>> doing it wrong)
>> - Fast page hash management.  Most kernels perform O(n) searches  
>> through the page hash when manually locating an entry.  I instead  
>> perform O(1) lookups.
>>
>> I recommend that you avoid looking at open source kernels for  
>> guidance.  They don't push the limits of PowerPC.
>>
>> -Josh
>>
>>
>>
>> On Feb 7, 2006, at 16:18, Matthias Lange wrote:
>>
>>> Hi,
>>>
>>> I am stuck with porting the Fiasco microkernel to PowerPC. I  
>>> can't find any clear documentation about how to setup a interrupt  
>>> description table. So, these are my questions:
>>>
>>> 1. How is an interrupt descriptor formed on PowerPC? How does it  
>>> look?
>>> 2. Where (in memory) do I need to store these descriptors?
>>>
>>> The IBM PowerPC Programming Manual gives me a good overview but  
>>> no information on how to implement it. Can someone please point  
>>> me to some meaningful documentation?
>>>
>>> Regards,
>>>
>>> Matthias.
>>>
>>
>>
>>
>
>
>