hello Adam,
I also have a question about the Interrupt mechanism in l4linux. I want to move some interrupts to specified cpu core. When I try to write to "/proc/irq/*/smp_affinity" with cpu bitmask, it will call the function l4lx_irq_dev_set_affinity(), which attachs the irq to corresponding vcpu thread. After that, I find the irq is still staying on previous cpu core through linux proc system. So I doubt whether linux proc filesystem's view is synchronized with the interrupt settings of the L4 kernel, or it can not be achieved in l4linux? (I use genode for the runtime environment of fiasco.oc)
Thank you!
At 2015-11-20 07:20:56, "Adam Lackorzynski" <adam@os.inf.tu-dresden.de> wrote:
>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@os.inf.tu-dresden.de
> Lackorzynski http://os.inf.tu-dresden.de/~adam/
>
>_______________________________________________
>l4-hackers mailing list
>l4-hackers@os.inf.tu-dresden.de
>http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers