L4Linux update? Driver support

[Adam Lackorzynski]

On Mon Nov 16, 2015 at 17:22:05 +0100, ba_f wrote:
> Am 2015-11-04 00:22, schrieb Adam Lackorzynski:
> >Hi,
> >
> >On Tue Nov 03, 2015 at 15:30:37 +0100, ba_f wrote:
> >>Am 2015-11-03 00:08, schrieb Adam Lackorzynski:
> >>>On Mon Nov 02, 2015 at 18:20:55 +0100, ba_f wrote:
> >>>>Is there something special to take care of?
> >>>
> >>>... take care that you use the L4XV_FN* wrappers and also do not block
> >>>long when doing calls because that will block L4Linux's vCPU. Best use
> >>>some asynchronous way of communication but at least make sure any calls
> >>>are replied soonish/immediately.
> 
> Can you be a bit more precise on this, please.
> What's the problem with L4Linux's vCPU blocking long?
> Does it crash, or is it just that all L4Linux threads get blocked as well?

It won't crash but VMs don't like to be stalled. A few seconds won't be
a problem generally but during that time everything inside the VM is
blocked. After some time (many dozen seconds) checking mechanisms will
kick telling that something is wrong because no scheduling is happening.
 
> A colleague of mine suggested that all L4Linux threads are automatically
> pushed into its own tasks, anyway, and such would not be affected by one
> blocking thread.
> Is this true?

No because in L4Linux there's only one thread (per host CPU) that
handles everything like running the Linux kernel code as well as user
process threads.

> >>unfortunately, my Server does some crypto stuff and thus is pretty slow.
> >
> >How long is long here? Couple of ms, or longer?
> 
> Some operations definitely take seconds.
> 
> 
> >>So, L4Linux gets blocked with Istream::receive() and IRQ::receive(),
> >>right?
> >
> >Receiving from an IRQ is actually pretty asynchronous, and you should
> >get IRQs the normal (L4)Linux way (do you?).
> 
> What do you mean by this?
> Using on-chip interrupt controller? Or some kind of internal microkernel
> IRQ?

In L4Linux, there's a l4x_register_irq(l4_cap_idx_t) function where you
get a Linux-internal irq number for an irq-cap. That returned irq number
is then used for request_irq (and friends) to implement a common
interrupt handler in a Linux driver. There are a couple of users of that
in L4Linux.

> If it is microkernel IRQ, i haven't figured out, yet, how to implement this
> without blocking.
> Is it possible? Are there examples?
> 
> >A receive() operation is
> >indeed blocking.
> >
> >>If this is true, i don't really see a clean way of an asynchronous
> >>communication, is there?
> >
> >There are some options but all are more complicated than just doing
> >l4_ipc_call. Some common and good way is to use shared memory and
> >notifications to exchange data. When you do crypto, are you shuffling
> >data around and maybe already have some shared memory? Alternatively,
> >your server could have some submit+fetch interface, with polling or even
> >a notification via an interrupt. Although this last one scores better on
> >the hacky-scale it should be faster to implement :)
> 
> Yes, i already have shared memory. Until now, I push its capability over an
> IPC::call().

That's ok.




Adam
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/