PowerPC interrupt setup
kay-uwe.genz at web.de
Fri Mar 3 00:13:59 CET 2006
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).
Thanks for the explanation
More information about the l4-hackers