[Adeos-main] Re: My first tests with adeos!!!

[Adeos-main] Re: My first tests with adeos!!!

[Karim Yaghmour]

Hello Mohan,

Cool testdrive ... ;)

BTW, there's an Adeos mailing list here: adeos-main@gna.org
That's the best place to send your mails to.

mohan kumar wrote:
> Now, i changed the way timer interrupt(0) is hanlded
> using the adeos_control_irq call. My understanding is
> that "it can control weather the interrupt is
> dispatched to lower priority domains" So i set my
> domains priority higher to linux and then made adeos
> not to send linux the interrrupts. I did this because
> i programmed the 8254 for more grannular interrupts
> and was going to dispatch the timer interrupt to linux
> only after 10ms.

Did you write the dispatching code? If you didn't then that's what's
hanging your system for sure.

> I tried with more interrupts down the line (2,3,..9)
> and see the same scenario happening.

In the example test case we provide, all interrupts are fed to
all the domains in the ipipe. Of course, if you start telling
Adeos not to pass interrupts to Linux, then you must have a
way to handle them.

I think the best way to get some help would be to post the code
you wrote for your domain. Otherwise, we can only guess, but not
much more ...

Cheers,

Karim

===================================================
                 Karim Yaghmour
               karim@domain.hid
      Embedded and Real-Time Linux Expert
===================================================

[Adeos-main] Re: My first tests with adeos!!!

[mohan kumar]

hi,
I assume that resetting the control word (with the
IPIPE_PASS_MASK bit set) will dispatch the interrupt
to the next domain. So i reset the control word once
every 100 interrupts and reset it in the next
interrupt.

Well, my code is not elobrate :)

cheers,
Mohan S

p.s:i am not subsribed to this mailing list. please cc
me the reply.

#include <linux/version.h>
#include <linux/module.h>
#include <linux/wrapper.h>
#include <linux/config.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/init.h>
#include <asm/system.h>
#include <asm/io.h>
#define INT_NUM 1

#if INT_NUM == 0
#define REPROGRAM_8254
#define LATCH_NEW LATCH/100
#endif

MODULE_LICENSE("GPL");

static adomain_t this_domain;

void timer_tick (void)

{
    static int i , mod;
    
    mod=(++i % 100);
    switch (mod)
    {
    case 0:
	    adeos_control_irq(INT_NUM,0,IPIPE_PASS_MASK);
	    break;
    case 1:
	    adeos_control_irq(INT_NUM,IPIPE_PASS_MASK,0);
	    break;
    default:
	    break;
    }

    __asm("iret");
}

void domain_entry (void)

{
    printk("Domain %s started.\n",adp_current->name);

    adeos_virtualize_irq( INT_NUM ,&timer_tick,NULL); 
  

adeos_control_irq(INT_NUM,IPIPE_PASS_MASK,0);    

    for (;;)
	/* This is this domain's idle loop. */
	adeos_suspend_domain();	/* Yield control back to
ADEOS. */
}
	

static int __init __adtest_init (void)

{
    int ret;
    adattr_t attr;
#ifdef REPROGRAM_8254
	outb_p(0x34,0x43);	
	outb_p(LATCH_NEW & 0xff , 0x40);
	outb(LATCH_NEW >> 8 , 0x40);
#endif
    attr.name = "TestDomain";
    attr.entry = &domain_entry;
    attr.estacksz = 0;	/* Let ADEOS choose a
reasonable stack size */
    attr.priority = ADEOS_ROOT_PRI + 1;
    
    ret = adeos_register_domain(&this_domain,&attr);
    return ret;
}

static void __exit __adtest_exit (void)

{
#ifdef REPROGRAM_8254
	outb_p(0x34,0x43);	
	outb_p(LATCH & 0xff , 0x40);
	outb(LATCH >> 8 , 0x40);
#endif	
    adeos_unregister_domain(&this_domain);
}

module_init(__adtest_init);
module_exit(__adtest_exit);




__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

[Adeos-main] Re: [rtai] Re: My first tests with adeos!!!

[Guennadi Liakhovetski]

> BTW, there's an Adeos mailing list here: adeos-main@gna.org
> That's the best place to send your mails to.

And how does one subscribe to it? Sorry, didn't find instructions
anywhere... Something like "send 'subscribe' to
adeos-requests@domain.hid"?...

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

[Adeos-main] Re: My first tests with adeos!!!

[mohan kumar]

sorry i put INT_NUM as 1 but its zero (actually it can
be anything)... but this is not a solution to the
problem :)

Cheers,
Mohan S


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

[Adeos-main] Re: [rtai] Re: My first tests with adeos!!!

[Wolfgang Denk]

In message <Pine.LNX.4.33.0206180928190.25522-100000@domain.hid> you wrote:
> > BTW, there's an Adeos mailing list here: adeos-main@gna.org
> > That's the best place to send your mails to.
> 
> And how does one subscribe to it? Sorry, didn't find instructions
> anywhere... Something like "send 'subscribe' to
> adeos-requests@domain.hid"?...

See

http://mail.freesoftware.fsf.org/mailman/listinfo/adeos-main

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@domain.hid
The biggest difference between time and space is that you can't reuse
time.                                                 - Merrick Furst

Re: [Adeos-main] Re: My first tests with adeos!!!

[Karim Yaghmour]

Hello Mohan,

I've taken a summary look at the code and I think the following is
the problem:

mohan kumar wrote:
> ...
>     case 0:
>             adeos_control_irq(INT_NUM,0,IPIPE_PASS_MASK);
>             break;
> ...

I don't think that adeos_control_irq() will work like this alone.
Have a look at arch/i386/ipipe.c:ipipe_handle_irq(). Notice that
the setting of interrupt flags for the various domains is done
prior to any domain handler being called. By disabling the passing
of the interrupts in domain_entry() as you do, all subsequent
interrupts are not passed on. What you actually do with
adeos_control_irq() in the interrupt handler only influences the
next round of interrupts. Given the code in the interrupt handler,
however, I think that you should be making the following call if
you want the interrupts to propagate the next time they occur:
adeos_control_irq(INT_NUM,IPIPE_PASS_MASK,1);

If you disabled the interrupt passing and would still want to
propagate the IRQ down the ipipe, then have a look at the latest
code in the CVS by Philippe. Particularily, try using
adeos_propagate_irq() in your handler.

Cheers,

Karim

===================================================
                 Karim Yaghmour
               karim@domain.hid
      Embedded and Real-Time Linux Expert
===================================================

Re: [Adeos-main] Re: My first tests with adeos!!!

[Karim Yaghmour]

Karim Yaghmour wrote:
> Given the code in the interrupt handler,
> however, I think that you should be making the following call if
> you want the interrupts to propagate the next time they occur:
> adeos_control_irq(INT_NUM,IPIPE_PASS_MASK,1);

My mistake. I mixed up the call's API. The original was OK:
adeos_control_irq(INT_NUM, 0 ,IPIPE_PASS_MASK);

The rest of the explanation still holds, however.

Karim

===================================================
                 Karim Yaghmour
               karim@domain.hid
      Embedded and Real-Time Linux Expert
===================================================

Re: [Adeos-main] Re: My first tests with adeos!!!

[mohan kumar]

hi,
I think iam not clear...

ok, i think the below code gotta work, but does not:)
I have registered for int 1 and controled the flow so
that it does not go to linux.

i compile the module and invoke it using

$ insmod adtest.o;sleep 1;rmmod adtest

since the keyboard int is not dispatched to linux i do
the insmod and rmmod commands oneshot.

It still hangs :(

I get the timer interrupts. But EVEN ADEOS is not able
to see other interrupts. Iam not able to telnet to the
machine or use the serial cable.

But i will work with the new code in CVS and mail u
the results.

Cheers,
Mohan S

/****adtest.c****/

MODULE_LICENSE("GPL");

static adomain_t this_domain;

void handler(void)
{
    __asm("iret");
}

void domain_entry (void)

{
    printk("Domain %s started.\n",adp_current->name);

    adeos_virtualize_irq( 1 ,&handler,NULL); 
    adeos_control_irq(1,IPIPE_PASS_MASK,0);    

    for (;;)
	/* This is this domain's idle loop. */
	adeos_suspend_domain();	/* Yield control back to
ADEOS. */
}
	

static int __init __adtest_init (void)

{
    int ret;
    adattr_t attr;
    attr.name = "TestDomain";
    attr.entry = &domain_entry;
    attr.estacksz = 0;	/* Let ADEOS choose a
reasonable stack size */
    attr.priority = ADEOS_ROOT_PRI + 1;
    
    ret = adeos_register_domain(&this_domain,&attr);
    return ret;
}

static void __exit __adtest_exit (void)

{
    adeos_unregister_domain(&this_domain);
}

module_init(__adtest_init);
module_exit(__adtest_exit);



__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Re: [Adeos-main] Re: My first tests with adeos!!!

[Philippe Gerum]

Hi Mohan,

mohan kumar writes:
 > hi,
 > I think iam not clear...

Now you are ;o)

I just want to let you know that I'm digging this problem (using your
code snippet) which also appears with the current CVS head
version. I'll tell you more asap. My first observations point to a
random bug in the deferred interrupt dispatch code when returning from
the user domain handler.

Btw, the current CVS version implements the basics of SMP support, but
it is _not_ complete. However, it still works (well on my test
platforms it does) in UP mode. If you want to fetch the older non-SMP
code, use the "pre-smp" tag when checking it out.

Finally, be aware that I've added some fields to the adattr_t domain
attribute struct to control additional functionalities. Mainly,
"domid" is just an external numerical domain id you can set to
anything but 0 (reserved to the root Linux domain), and "dswitch"
which is a domain switch handler called each time the domain is
resumed by Adeos to process interrupts. 

 > 
 > But i will work with the new code in CVS and mail u
 > the results.

Thanks.

Cheers,

Philippe.

[Adeos-main] Address spaces in adeos

[Jacob Gorm Hansen]

Hi,

just curious,

do you guys have any plans to implement protected address spaces, and means of
communicating between them (like ipc)? There are some scenarios in which
operating systems cannot be trusted not to sabotage eachother.

best,
Jacob

Re: [Adeos-main] Re: My first tests with adeos!!!

[Philippe Gerum]

Hi Mohan,

Good news! I found the problem you encountered while hooking the
keyboard IRQ. Basically, I forgot to save a bunch of potentially
clobbered registers in the inline assembly code that calls the domain
handler. Other problems have been fixed too. All this leads to the
following updates in the current CVS tree:

1. adeos_virtualize_irq() now takes a 4th "modemask" argument which
specifies the initial IRQ control mode so that you don't have to call
adeos_control_irq() immediately after for the same purpose. Moreover,
this is nicely atomic as far as interrupt preemption is concerned.
Finally, a different handling of the "acknowledge" function pointer is
done. Passing NULL used to delegate the IRQ acknowledging to the next
domain down the pipeline able to perform it (i.e. having a non-zero
acknowledge routine pointer). Now, passing a NULL acknowledge routine
tells Adeos to use the ack routine defined by the root (Linux) domain
for the same IRQ. If you really don't want anyone down the pipeline
to ack the IRQ, just pass a pointer to an empty C routine returning
a non-zero value.

2. You can now specify one of the next two calling conventions for
your IRQ handler:

- The default one makes Adeos call your domain-specific IRQ handler
like a C routine, with the irq # stacked as its sole argument
(i.e. void my_kbd_handler(unsigned irq)).

- The other one makes Adeos assume that your handler is an assembly
routine.

The difference is important: when calling a C routine, Adeos saves and
restores the CPU registers automatically for you, so that your handler
can clobber them without any risk.  Conversely, using an assembly
calling convention tells Adeos that your routine handles the
appropriate register backup/recovery stuff according to which
registers are clobbered by your code. Moreover, you _must_ exit your
handler with an __asm("iret") instruction, and *not* a regular
"ret". On entry, %eax is loaded with the IRQ number. Linux handlers
use the assembly calling convention (see
linux/arch/i386/kernel/traps.c), while you will likely prefer using a
nice regular C routine to handle the interrupts Adeos passes to your
domain.

The calling convention can be selected using the new "modemask"
argument passed to adeos_virtualize_irq(): add IPIPE_CALLASM_MASK to
the mode mask to declare an assembly calling convention, otherwise,
the C calling convention will be applied by default.

Here is your code snippet, slightly modified to take these updates in
account. You will find that the keyboard IRQ is marked as "dynamic" in
adeos_virtualize_irq(), which means "IPIPE_HANDLE only and let the
handler decide". The handler can then invoke adeos_propagate_irq() to
pass the interrupt down the pipeline if he wants to, or do nothing,
which is equivalent to "don't pass". You will notice that the keyboard
IRQ _must_ be passed to Linux when your are done with it. If you don't
the keyboard driver state will be wrecked since some mandatory
processing is performed on behalf of the regular Linux keyboard
handler... :o> (in any case, the keyboard interrupt is a special beast
here since the keyboard softirq handler happens to sit in a busy wait
loop for supplemental kbd IRQs).

Philippe.

--

#include <linux/version.h>
#include <linux/module.h>
#include <linux/wrapper.h>
#include <linux/config.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/init.h>
#include <asm/system.h>

MODULE_LICENSE("GPL");

static adomain_t this_domain;

void handler(unsigned irq)

{
    printk("CAUGHT IRQ #%d\n",irq);
    adeos_propagate_irq(1);
}

void domain_entry (void)

{
    printk("Domain %s started.\n",adp_current->name);

    adeos_virtualize_irq(1,&handler,NULL,IPIPE_DYNAMIC_MASK);

    for (;;)
	/* This is this domain's idle loop. */
	adeos_suspend_domain();	/* Yield control back to ADEOS. */
}
	
static int __init __adtest_init (void)

{
    adattr_t attr;

    attr.name = "TestDomain";
    attr.domid = 1;		/* Anything but 0 */
    attr.entry = &domain_entry;
    attr.estacksz = 0;	/* Let ADEOS choose a reasonable stack size */
    attr.priority = ADEOS_ROOT_PRI + 1;
    attr.dswitch = NULL;	/* Domain switch hook - always a C routine */

    return adeos_register_domain(&this_domain,&attr);
}

static void __exit __adtest_exit (void)

{
    adeos_unregister_domain(&this_domain);
}

module_init(__adtest_init);
module_exit(__adtest_exit);

Re: [Adeos-main] Address spaces in adeos

[Karim Yaghmour]

Hello Jacob,

Jacob Gorm Hansen wrote:
> do you guys have any plans to implement protected address spaces, and means of
> communicating between them (like ipc)? There are some scenarios in which
> operating systems cannot be trusted not to sabotage eachother.

This is one of the scenarios which was discussed in the original
announcement. It is foreseeable, for instance, to have 2 OSes running
in the same RAM, each within its own physical boundaries:
Kernel A: 0-64MB
Kerbel B: 64-128MB

As with other nanokernels, the main mechanism to communicate between
such kernels would be soft interrupts. We could even foresee another
scenario where there's one part of the RAM that is reserved for
setting up shared memory regions between OSes.

There are 2 main "problems" in all these such scenarios:
1- There is no protection for physical accesses since all OSes have
can directly play with the hardware.
2- Page faults must be sent to the faulty domain only.

#2 is not really that hard to solve. We need to implement a page fault
demux which sends the page fault to the current domain only.

There is, unfortunately, no real way to get around #1 without adding
extra virtualization layers. Since we are assuming stable kernels
with "intelligent" code, however, then it should not be a problem.

Karim

===================================================
                 Karim Yaghmour
               karim@domain.hid
      Embedded and Real-Time Linux Expert
===================================================

Re: [Adeos-main] Address spaces in adeos

[Jacob Gorm Hansen]

On Thu, Jun 20, 2002 at 12:21:56AM +0000, Karim Yaghmour wrote:
> 
> There are 2 main "problems" in all these such scenarios:
> 1- There is no protection for physical accesses since all OSes have
> can directly play with the hardware.
> 2- Page faults must be sent to the faulty domain only.
> 
> #2 is not really that hard to solve. We need to implement a page fault
> demux which sends the page fault to the current domain only.
> 
> There is, unfortunately, no real way to get around #1 without adding
> extra virtualization layers. Since we are assuming stable kernels
> with "intelligent" code, however, then it should not be a problem.

We are currently trying to make L4Linux (linux2.2 running on the L4
micro kernel) boot several in L4Linux instances.

The good thing about L4 is that it gives us address space protection and
IPC, but sometimes the 'every linux tasks is an l4 task' way of doing 
things seems a bit much.

We want to be able to migrate entire OSes between machines, and thus we
cannot trust the OSes to be friendly or correct.

If we had the time, it seems that implementing protection in adeos would
be interesting and easier to work with than L4 (which is a very nice 
u-kernel btw).

/Jacob

Re: [Adeos-main] Address spaces in adeos

[Karim Yaghmour]

Jacob Gorm Hansen wrote:
> We are currently trying to make L4Linux (linux2.2 running on the L4
> micro kernel) boot several in L4Linux instances.
> 
> The good thing about L4 is that it gives us address space protection and
> IPC, but sometimes the 'every linux tasks is an l4 task' way of doing
> things seems a bit much.
> 
> We want to be able to migrate entire OSes between machines, and thus we
> cannot trust the OSes to be friendly or correct.
> 
> If we had the time, it seems that implementing protection in adeos would
> be interesting and easier to work with than L4 (which is a very nice
> u-kernel btw).

L4 is very interesting indeed. Last I read about it, though, its
licensing was problematic (i.e. couldn't be released "open source"
because of the funding of the project) and it is very hardware dependent
(in order to achieve better performance). Is this still true?

I understand the need to be able to migrate entire OSes between
machines. Because we do not virtualize the physical RAM, this
may a little harder to do with Adeos. But since we assume that
we can modify the OSes to better interact with Adeos, then it
should not be that much harder to implement code that "rewires"
the kernels' mappings. Of course, this would require some work,
and time ... ;)

Cheers,

Karim

===================================================
                 Karim Yaghmour
               karim@domain.hid
      Embedded and Real-Time Linux Expert
===================================================

Re: [Adeos-main] Address spaces in adeos

[Jacob Gorm Hansen]

On Thu, Jun 20, 2002 at 12:22:37PM -0400, Karim Yaghmour wrote:
> 
> L4 is very interesting indeed. Last I read about it, though, its
> licensing was problematic (i.e. couldn't be released "open source"
> because of the funding of the project) and it is very hardware
> dependent (in order to achieve better performance). Is this still
> true?

No. The latest implementations are GPL, and large parts written in C++.

But i386 is still the main supported platform, even though ports for
MIPS and ARM exist.

> I understand the need to be able to migrate entire OSes between
> machines. Because we do not virtualize the physical RAM, this
> may a little harder to do with Adeos. But since we assume that we can
> modify the OSes to better interact with Adeos, then it should not be
> that much harder to implement code that "rewires" the kernels'
> mappings. Of course, this would require some work, and time ... ;)

Yes the recursive address spaces in L4 are a very good thing
for our needs. The only problem is that because all linux processes
are mapped to l4 tasks, there is thread info inside l4 which we 
need to checkpoint and which is hard to get. A nanokernel might be more
helpful because guest kernels could then do their own scheduling, and
the entire kernel would be easy to migrate as one block of memory.

Best,
Jacob