PowerPC interrupt setup

[Kay-Uwe.Genz]

Hi Joshua,

Am 01.03.2006 um 08:43 schrieb Joshua LeVasseur:

>
> Hi Kay-Uwe,
>
> Sorry about the slow response; super busy here.

Don't worry, I'm very glad to get such a detailed answer. Thanks,  
this was helping to understand things better.

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

I take a deeper look in the darwin kernel sources and yes, it seems  
that they try to get the MMU running as fast as possible.

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

My biggest mistake in thinking about the kernel in virtual mode was,  
to see the kernel as a unchangeable adress space. But the kernel is  
more an extension of a task and I can map both segments (source and  
destination) in the kernels adress space and if I switch the thread  
the mapping is changed (switched) also. This seems to work  
(theoretical, programming need more time). So it is no more than  
change the PPC Segment-Registers by thread switches.

>
>> 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 the explanation

Regards

Kay-Uwe