Hi Stefan, We did finally manage to get it working! The problem was the Pistachio kernel's support for IO Flex pages doesn't work - and non-virtual TCB are needed atleast with SMP enabled. New mapping seems OK. My next step is to try to build the rest of the Genode demo.

Do you plan to extend Genode's cpu-session interface to support an explicit cpu-migration of threads, or do you want to do load-balance somehow implicitly?

As far as this, I am currently not sure. We are really just surveying the landscape and seeing what we can get to work, as well as gaining a better understanding of where things are. We are actually looking at extending Pistachio to a multikernel for multicore processors - ultimately.

Thanks for the help, Daniel

-----Original Message----- From: Stefan Kalkowski [mailto:stefan.kalkowski@...1...] Sent: Friday, January 14, 2011 7:57 AM To: genode-main@lists.sourceforge.net Subject: Re: SMP ia32 support with Pistachio

Hello Daniel,

On 01/14/2011 12:52 AM, Daniel Waddington - SISA wrote:

...

Hi,

Has anyone managed to get Pistachio+Genode with SMP+ia32 running? We have managed to get Pistachio+Genode+ia32 without SMP working fine.

that's nice to hear!

...

As soon as we compile SMP it goes into an endless loop.

Any ideas?

Well, I'm not sure what you exactly mean by 'it goes into an endless loop'. Do you mean the kernel or Genode's core? Do you have some serial output, or can you even enter the kernel-debugger?

In fact we normally only use the single-processor version of pistachio. Nevertheless, we've tested SMP support today, and there seems to be a general problem with SMP in the current version of pistachio. We got different races sometimes even before 'core' (Genode's roottask) got started.

In older versions of pistachio, SMP support seems to work, but there we got minor problems with the old mapping-database. Possibly the SMP version doesn't use the new mapping database implementation, at least in the version we've tested (from 08.01.2010). Probably, Genode can easily be reworked to use the old mapping semantic, but it has known stability problems.

I think a better way is to solve the presumptive, current SMP support problem in pistachio directly. You might ask the pistachio developers for help[1]. Maybe you can reproduce the SMP problems with a tiny example application?

Once, the pistachio port of Genode (formerly known as Bastei) was done by Julian Stecklina[2] as study work, he successfully implemented rudimentary SMP support into the cpu-session interface of Genode. So at least at that point SMP worked with the predecessor of Genode together, but that experimental code isn't part of Genode today.

Do you plan to extend Genode's cpu-session interface to support an explicit cpu-migration of threads, or do you want to do load-balance somehow implicitly?

...

Thanks Daniel Waddington

You're welcome.

regards Stefan Kalkowski

[1] http://l4ka.org/maillist.php [2] http://os.inf.tu-dresden.de/papers_ps/jstecklina-beleg.pdf

-- Stefan Kalkowski 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

---

---

Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

Hello Vasileios,

this is my first posting. I was reading the interesting paper "Omega0: A portable interface to interrupt hardware" . I would like to ask if there is any implementation for this paper and if it is adapted to the Intel IOAPIC specification

an Omega0-like service is included in Genode's core component. It completely hides kernel-specific details. The service is called IRQ and has a very simple interface (much simpler than the original Omega0 design):

http://genode.org/documentation/api/static_content/code/base/include/irq_ses...

Attaching to an IRQ is done by opening a session to the IRQ service and supplying the IRQ number as session argument. To wait for an IRQ, the client performs a synchronous RPC ('wait_for_irq'). By invoking this function, the respective IRQ gets unmasked at the IRQ controller (how exactly depends on the kernel and the hardware). The 'wait_for_irq' call blocks until an IRQ occurs. Analogously to unmasking the IRQ on the 'wait_for_irq' call, the IRQ gets masked when 'wait_for_irq' returns.

This implementation overcomes two problems described in the original Omega0 paper. First, the IRQ service can be resolved using the normal Genode session mechansim. No special name service or magic is needed. Second, a vanishing driver gets detected implicitly by Genode's session-close mechanism.

However, one disadvantage of Omega0 prevails: For each IRQ, there is an additional hop between the kernel and the IRQ-handling device driver. However, depending on the used kernel, this issue can be alleviated. For example, on NOVA, the first 'wait_for_irq' call could map the kernel's IRQ semaphore to the client. The client could then block directly using this kernel object. For the driver implementation, this optimization is completely transparent. (Note that is optimization is not implemented yet but for reference, a similar approach is already employed by the NOVA-specific SIGNAL service)

Regarding shared interrupts, we have addressed this issue on OKL4 (but our solution is not limited to this kernel): Multiple clients are able to open an IRQ session with the same IRQ number. The respective IRQ gets unmasked as soon as all clients have called 'wait_for_irq'. This may be a problem if one of those drivers is bugged. If such a driver refuses to call 'wait_for_irq', no other driver attached to the same IRQ will receive interrupts. However, this problem is inherent to shared IRQs.

Last, IOAPIC support is currently provided by the NOVA and Fiasco.OC kernels. On these kernels, the legacy PIC IRQ numbers are not used anymore. Instead, each IRQ source is referred to by a so-called global system interrupt (GSI) number. However, the first 15 GSIs are normally corresponding to their respective PIC numbers (except for the timer that moved from IRQ 0 to GSI 2). On Genode, we have not yet implemented general support for GSIs except for the remapping of the timer interrupt. In the future, we plan to let core's IRQ session take kernel-native IRQ numbers (in the case of NOVA and Fiasco.OC that would be GSIs) as argument and perform the remapping of IRQ-session arguments according to the system's IRQ routing in a separate service. This service would intercept the creation of IRQ sessions and perform the needed translation.

Best regards Norman