Re: [Trion-kernel-dev] trion reloaded

[Daniel R. <cos...@gm...>]

Hello Manuel

> Why does each CPU set up an own GDT, IDT and page tables? The entries in
> all the GDT's will be identically, so it would be sufficient to use only
> one.

You have some point here, a single gdt/idt per system should indeed be  
sufficient..

> But I can't see the advantage in having multiple IDT's (and also multiple
> interrupt stubs, calling the same interrupt handler).

I've read somewhere that, on uniprocessor machines, it can actually be  
usefull
to create one stub for each interrupt to save the time that it would take  
to
check the PIC registers in order to find out which interrupt was fired.  
With a
multi-processor system this however is of course no problem any more as  
the local
APIC is located on the CPU itself so that its registers can be read-out  
very fast.
I'll thus split CreateIDTEntry() into two procedures (create a new stub,  
link
interrupt with stub) so that either of the two methodes may be used in the  
future.

> Finally, multiple page tables allow all CPU's to see the same virtual
> memory layout while having their data at different locations within
> physical memory, but I wonder whether this justifies the memory overhead
> causes by the page tables.

It's actually only a single page-table (4kb) per cpu that is meant to  
describe the
first 4mb of kernel-space. These 4mb would have a different mapping on  
each node and
might therefore be used to store per processor information like, for  
example, a
structure containing pointers to all of the cpu's hal-object:

0xE8000000   - kernel image
+ image_size -  my   hal structures
+ hal_size   - cpu 0 hal structures
+ hal_size   - cpu 1 hal structures
+ hal_size   - cpu n hal structures

If a systemcall is triggered the cpu may easily get the location of it's  
hal structures
as their address is, due to the different mappings on each cpu, static  
throughout the
whole system. I'm myself however not quite sure it this is really the most  
convenient way
of retrieving this iformation. The two alternatives I could think of are  
to either store
the structure relativ to the cpu's kernel stack-pointer (somewhat hackish)  
or to use the
local APIC's id as some sort of an index (not sure how easy/fast it can be  
obtained).

Any opinions about this ?

> The kernel entry is not (yet) thread safe. As soon as an AP boots up and
> enters main(), it will clobber some global variables (stack, nodestruct  
> and
> so on) since they exist only once as part of the kernel.

As the processor number is passed to the C entrypoint this could probably  
be avoided
quite easily. You're however right that the framework as a whole isn't all  
that elaborated
yet and I'll see if I can have a look at it this week-end.

> I'll try to add some mp requirements (locks...) and APIC features (timer,
> IPI) during the next days.

Excellent..

regards,
cosmo86