Interrupts in L4Linux

[Norman Feske]

Hi Alexander,

> I'm currently implementing an X86 PCI bus driver for L4Linux as a
> temporary solution for
> getting USB support in L4Linux.

you are taking our port of L4Linux into an interesting direction. So
far, we have deliberately kept our version of L4Linux void of any
device-driver functionality and used it as a mere runtime environment
for Linux programs. Can you give me a bit of background information
behind your work? Are you going to use L4Linux as a device-driver OS,
providing Genode service interfaces? Or do you just want to grant Linux
access to (a subset of) real devices to avoid the need for native Genode
device drivers and session interfaces for those devices?

> Current genode-side code is presented below. The l4linux patch is not
> ready, but I've
> submitted the relevant part of the diff to pastebin (it's only
> makefile and kconfig anyway)
> 
> https://github.com/Ksys-labs/genode/blob/pci_wip/ports-foc/src/drivers/genode_pci.c
> https://github.com/Ksys-labs/genode/blob/pci_wip/ports-foc/src/lib/l4lx/genode_pci.cc
> https://github.com/Ksys-labs/genode/blob/pci_wip/ports-foc/src/lib/l4lx/l4_io.cc
> http://pastebin.com/9c37tuJR

That looks good to me.

> So, the question is, why is interrupt handling broken and the only
> working interrupt in l4linux is timer
> which actually uses L4 timer ipc instead of irq and how this should be
> fixed.

The reason is plain and simply that our version of L4Linux was never
meant to access devices directly. I am surprised that you got that far. :-)

> Also, what do you think
> of making a "genode" arch for linux and getting rid of l4linux which
> uses the Fiasco.OC API bypassing
> Genode interfaces?

As you described in your article, the current situation is not exactly
beautiful. We have a patched version of Linux (L4Linux) with the
original git history gone due to L4Linux' way of releasing snapshots via
SVN. Then, we put some patches in top, along with a LRre emulation
library. Finally, we garnish the whole thing with some Genode-specific
stub drivers.

So why have we chosen this path? We thought that this way minimizes our
ongoing investment with maintaining the Genode version of L4Linux. TUD
is taking care of adapting L4Linux to changes of the Fiasco.OC kernel
interface. So we don't have to do that. But TUD is targeting L4Re only
and does not care about Genode. So to leverage their work, we need our
custom L4Re emulation library, which hopefully is pretty simple (that is
actually true) and easy to maintain. This approach worked well as long
as we did not do any invasive changes to L4Linux and use it just as is.
Now, that you are pushing the boundaries a bit more and making more
intensive use of L4Linux, I can clearly see how the construct becomes a
burden for you.

Regarding your last question, sure, I would welcome to remove several
levels of indirection that we currently rely on. The cleanest solution
would certainly be to fork the vanilla Linux kernel and implement
paravirtualization using Genode primitives only, thereby taking L4Linux
and the L4Re emulation library out of the loop. On the other hand, I
cannot really justify putting much effort into that because I regard
virtualized Linux just as a stop-gap solution for running existing
software until Genode supports it natively. Naturally, I would prefer to
dedicate my energy on developing the native Genode environment instead.

Also, for the x86 architecture, there exists the Vancouver VMM, which is
not only actively developed in the open but their core developers
cooperate closely with us (see
https://github.com/genodelabs/genode/issues/666). So for x86 with
hardware virtualization, I see no advantage of a paravirtualized Linux
over the Vancouver VMM. We can just use Linux unmodified. The only
difference is that Vancouver works on NOVA only, not Fiasco.OC ATM.

This leaves only ARM as the target platform where L4Linux seems to be
most suitable. However, since Cortex-A15 CPUs come with hardware
virtualization support, I find it more tempting to explore this route
rather than investing time in pursuing the paravirtualization of the
Linux kernel.

That is of course just my line of thinking. If you like to go forward
with developing a replacement for L4Linux that removes from the
superficial indirections that plague you today, this would be very
welcome and I'd certainly provide assistance if needed.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth