Re: Thoughts about the new X.2 spec...

[Farid Hajji]

> Farid Hajji wrote:
> > ... The mapping of IO pages to driver adress spaces is also incredibly
> > useful and could improve performance a lot. ...
> 
> IO pages have been lurking around in L4 specifications at least since
> Version 2, but have never been implemented before. They allow to securely
> manage access to the x86' IO space. Read as: We now also include the x86'
> second address space in L4's address space notion. Previously EVERY thread
> was allowed to use in/out instructions.
> To avoid misreading here, introducing IO pages DOES NOT improve performance.
> It may improve security in that now you CAN control what address space's
> threads can access what IO ports.

Of course you're right. Mapping IO pages itself doesn't improve performance.
It's the fact that drivers in different address spaces can map IO pages
from the same interrupt handling thread's adress space instead of having
to copy the data that improves performance here.

I was already thinking ahead w.r.t. a driver architecture which resembles
somewhat this:

 +------------------------+
 |   Int-Handler thread   |
 | ...................... |          +----------+
 |  list of reg. drivers  |--------->| Driver 1 |
 +------------------------+\         +----------+
                            \        +----------+
                             \------>| Driver 2 |
                              \      +----------+
                               \     +----------+
                                \--->| Driver 3 |
                                     +----------+

Here, Driver 1, 2 or 3 would map the IO fpages from Int-Handler
instead of getting the data in messages. IPCs from the int handler
to the drivers would only function as triggers/notifications.

If I understood X.2 correctly, this is not the only possible
architecture. Driver i could also issue a IPC receive from anythread
to get notification of the interrupt directly. But here, if multiple
drivers are listening to notifications, only the driver that actually
handles the interrupt should re-enable it. I see difficulties here
w.r.t. synchronization between all those Drivers, if they run
in parallel threads:

1. If Driver i handles the interrupt, it must wait for all other
   Drivers (of the same class) to leave their critical regions
   before issuing an interrupt-reenable IPC to the hardware-thread.
   If this is not done, race conditions could easily occur.

2. At most one Driver i would handle the interrupt. It would not
   be possible to have an interrupt handled by multiple Drivers
   simultaneously. Perhaps each driver should daisy-chain the
   interrupt by throwing it to the next driver in the chain?

3. If no Driver handles the interrupt, who will then re-enable it?

So the easier method would be for now to centralize the re-enabling
of interrupts in a dedicated interrupt-handler thread as shown above,
rather than have the Drivers sort this out between themselves.

Sorry for sloppy formulations ;)

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.