Nabble - L4Ka

Re: booting question

2009-09-06T18:13:26Z

Finally I get this work, it is the problem that floppy image (fdimage.img) did not contain valid file system. I follow the section 2 to create floppy image that doesn't require root prvilage. Is there any chance to update the getting started page (http://l4ka.org/projects/pistachio/ia32/gettingstarted.php)? I think that would help newbie like me.

Thanks for help.

neo anderson wrote:

I follow the guide at http://l4ka.org/projects/pistachio/ia32/gettingstarted.php. but whilst executing to the step to startup from qemu (qemu -fda fdimage.img), the screen is always stops at grub menu.

grub> _

The config (config.out) is as below. Anything I did wrong? Thanks in advice. (In addition, the command I run almost the same as what stated in the guide, so there is no error shown while following those steps.)

#
# Automatically generated, don't edit
#
# Generated on: zion
# At: Fri, 07 Aug 2009 12:57:52 +0000
# Linux version 2.6.30-1-686-bigmem (Debian 2.6.30-5) (maks@debian.org) (gcc version 4.3.3 (Debian 4.3.3-15) ) #1 SMP Mon Aug 3 17:32:39 UTC 2009

#
# Pistachio Kernel Configuration System
#

#
# Hardware
#

#
# Basic Architecture
#
CONFIG_ARCH_X86=y
CONFIG_ARCH_POWERPC=n
CONFIG_ARCH_POWERPC64=n

#
# X86 Processor Architecture
#
CONFIG_SUBARCH_X32=y
CONFIG_SUBARCH_X64=n

#
# Processor Type
#
CONFIG_CPU_X86_I486=n
CONFIG_CPU_X86_I586=y
CONFIG_CPU_X86_I686=n
CONFIG_CPU_X86_P4=n
CONFIG_CPU_X86_K8=n
CONFIG_CPU_X86_C3=n
CONFIG_CPU_X86_SIMICS=n

#
# Platform
#
CONFIG_PLAT_PC99=y

CONFIG_SMP=n

#
# Miscellaneous
#
CONFIG_IOAPIC=n

#
# Kernel
#
CONFIG_IPC_FASTPATH=n
CONFIG_DEBUG=y
CONFIG_DEBUG_SYMBOLS=n
CONFIG_EXPERIMENTAL=n
CONFIG_PERFMON=n
CONFIG_SPIN_WHEELS=n
CONFIG_NEW_MDB=n
CONFIG_X86_SMALL_SPACES=n

#
# Debugger
#
CONFIG_KDB=y

#
# Kernel Debugger Console
#
CONFIG_KDB_CONS_KBD=y
CONFIG_KDB_CONS_COM=n

CONFIG_KDB_DISAS=n
CONFIG_KDB_ON_STARTUP=n
CONFIG_KDB_BREAKIN=n
CONFIG_KDB_BREAKIN_BREAK=n
CONFIG_KDB_BREAKIN_ESCAPE=n
CONFIG_KDB_INPUT_HLT=n
CONFIG_KDB_NO_ASSERTS=n

#
# Trace Settings
#
CONFIG_VERBOSE_INIT=n
CONFIG_TRACEPOINTS=n
CONFIG_KMEM_TRACE=n
CONFIG_TRACEBUFFER=n

#
# Code Generator Options
#

#
# Derived symbols
#
CONFIG_HAVE_MEMORY_CONTROL=n
CONFIG_X86_PSE=y
CONFIG_BIGENDIAN=n
CONFIG_X86_SYSENTER=n
CONFIG_X86_PGE=n
CONFIG_X86_FXSR=n
CONFIG_IS_32BIT=y
CONFIG_X86_HTT=n
CONFIG_X86_PAT=n
CONFIG_IS_64BIT=n
CONFIG_MULTI_ARCHITECTURE=n
CONFIG_X86_EM64T=n
CONFIG_X86_SMALL_SPACES_GLOBAL=n
CONFIG_X86_TSC=y
#
# That's all, folks!

booting question

2009-08-09T15:04:37Z

I follow the guide at http://l4ka.org/projects/pistachio/ia32/gettingstarted.php. but whilst executing to the step to startup from qemu (qemu -fda fdimage.img), the screen is always stops at grub menu.

grub> _

The config (config.out) is as below. Anything I did wrong? Thanks in advice. (In addition, the command I run almost the same as what stated in the guide, so there is no error shown while following those steps.)

#
# Automatically generated, don't edit
#
# Generated on: zion
# At: Fri, 07 Aug 2009 12:57:52 +0000
# Linux version 2.6.30-1-686-bigmem (Debian 2.6.30-5) (maks@...) (gcc version 4.3.3 (Debian 4.3.3-15) ) #1 SMP Mon Aug 3 17:32:39 UTC 2009

#
# Pistachio Kernel Configuration System
#

#
# Hardware
#

#
# Basic Architecture
#
CONFIG_ARCH_X86=y
CONFIG_ARCH_POWERPC=n
CONFIG_ARCH_POWERPC64=n

#
# X86 Processor Architecture
#
CONFIG_SUBARCH_X32=y
CONFIG_SUBARCH_X64=n

#
# Processor Type
#
CONFIG_CPU_X86_I486=n
CONFIG_CPU_X86_I586=y
CONFIG_CPU_X86_I686=n
CONFIG_CPU_X86_P4=n
CONFIG_CPU_X86_K8=n
CONFIG_CPU_X86_C3=n
CONFIG_CPU_X86_SIMICS=n

#
# Platform
#
CONFIG_PLAT_PC99=y

CONFIG_SMP=n

#
# Miscellaneous
#
CONFIG_IOAPIC=n

#
# Kernel
#
CONFIG_IPC_FASTPATH=n
CONFIG_DEBUG=y
CONFIG_DEBUG_SYMBOLS=n
CONFIG_EXPERIMENTAL=n
CONFIG_PERFMON=n
CONFIG_SPIN_WHEELS=n
CONFIG_NEW_MDB=n
CONFIG_X86_SMALL_SPACES=n

#
# Debugger
#
CONFIG_KDB=y

#
# Kernel Debugger Console
#
CONFIG_KDB_CONS_KBD=y
CONFIG_KDB_CONS_COM=n

CONFIG_KDB_DISAS=n
CONFIG_KDB_ON_STARTUP=n
CONFIG_KDB_BREAKIN=n
CONFIG_KDB_BREAKIN_BREAK=n
CONFIG_KDB_BREAKIN_ESCAPE=n
CONFIG_KDB_INPUT_HLT=n
CONFIG_KDB_NO_ASSERTS=n

#
# Trace Settings
#
CONFIG_VERBOSE_INIT=n
CONFIG_TRACEPOINTS=n
CONFIG_KMEM_TRACE=n
CONFIG_TRACEBUFFER=n

#
# Code Generator Options
#

#
# Derived symbols
#
CONFIG_HAVE_MEMORY_CONTROL=n
CONFIG_X86_PSE=y
CONFIG_BIGENDIAN=n
CONFIG_X86_SYSENTER=n
CONFIG_X86_PGE=n
CONFIG_X86_FXSR=n
CONFIG_IS_32BIT=y
CONFIG_X86_HTT=n
CONFIG_X86_PAT=n
CONFIG_IS_64BIT=n
CONFIG_MULTI_ARCHITECTURE=n
CONFIG_X86_EM64T=n
CONFIG_X86_SMALL_SPACES_GLOBAL=n
CONFIG_X86_TSC=y
#
# That's all, folks!

RE: issue in afterburner--same as " Afterburner running problem" thread

2009-04-24T01:29:24Z

> now when i do "make run-qemu" as mentioned in readme.txt, the boot
> process
> starts but when it tries to load the ramdisk, it gets struck there and
> nothing
> comes up after that.

Ok since there are many possible failure scenarios, I don't have a standard answer. In general, however, you want to find out what the guest and monitor are doing. A couple of options to do this:

- Use L4 Tracepoints, a source code based tracing facility to log predefined kernel and user events such as IPC, page faults, etc. Tracepoints are configured and used via KDB ("r"); they must be enabled in the pistachio kernel menu. You can instruct KDB to print the event to the console and/or to enter KDB upon the event.
- Use L4 Tracebuffer, a memory buffer that logs all the kernel and user tracepoints into an in-memory log buffer. Tracepoints are also configured and used via KDB ("y"); they must also be enabled in the pistachio kernel menu.
- Find out, via KDB and the binary executables, where guest and monitor are running and what data is contained on their stack. You can do so by again using KDB to inspect TCBs, stack pointer, instruction pointer and the memory they are referencing.

Best,
-Jan

--
Jan Stoess
System Architecture Group
University of Karlsruhe
Phone: +49 (721) 608-4056
Fax: +49 (721) 608-7664
eMail: stoess@...

issue in afterburner--same as " Afterburner running problem" thread

2009-04-22T11:15:28Z

Hi

One more problem here :)

I tried using afterburner also. did the stuff mentioned in readme.txt.

I was able to create a bootable iimage as mentioned.

now when i do "make run-qemu" as mentioned in readme.txt, the boot process
starts but when it tries to load the ramdisk, it gets struck there and nothing
comes up after that.

It is same as the issue mentioned in previous thread named " Afterburner running
problem:".

I entered in kdb and looked into the stuff. things look good there.i saw some
irq's, roottask and some other stuff there in schedule q.

can you please suggest what more needs to be chacked and what can be wrong here.

thanks

Check out my photos on Facebook

2009-04-16T19:26:21Z

Facebook

facebook

Muhammad Saufy Rohmad has:
89 friends
1 photo
1 note
42 wall posts
2 groups

Check out my photos on Facebook

Hi L4ka,

I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile.

Thanks,
Muhammad

To sign up for Facebook, follow the link below:

http://www.facebook.com/p.php?i=546038458&k=3XCU54UZSXVM51AAVEW5TP&r

l4ka@... was invited to join Facebook by Muhammad Saufy Rohmad. If you do not wish to receive this type of email from Facebook in the future, please click here to unsubscribe.
Facebook's offices are located at 156 University Ave., Palo Alto, CA 94301.

Re: [PATCH] fix improper return of local sender TID in propagated IPC

2009-04-09T08:36:36Z

On Wed, Apr 08, 2009 at 02:24:24PM +0200, Jan Stoess wrote:

> Thanks for the patch. It makes sense to me, and I have committed it to the
> repository. Apparently the local ID logic doesn't handle the propagation
> case very well.
>

No doubt there could be a more elegant solution as well, but that one seems
to do the locally right thing, for what it's worth.

> > As requiring that the VirtualSender TCR always contain a global TID when
> > propagation is specified in the message tag, I'd like to recommend that
> > the L4.X2 spec be revised accordingly.
>
> Hmm. I actually wouldn't want change the spec. The implementation follows
> the spec, not vice versa. And just because the implementation doesn't
> handle every (corner) case or contains bugs, I don't see any conceptual
> reason why local IDs shouldn't be used when propagating messages.
>

That sounds reasonable too, i.e. the kernel can convert a local ID in
VirtualSender to the appropriate ID for returning to the IPC recipient where
necessary -- entirely regardless of which format the ID given by the IPC
sender was in.

It's good to know this was just an implementation artifact.

> > [2] IMO, silently disabling propagation is the wrong thing to do as it
> > tells the sender that the IPC operation succeeded as specified when it
> > did not. This behaviour also diverges from that of Pistachio 0.4 .
>
> That's debatable. The spec says: "If originator thread and current sender,
> or current sender and receiver reside in the same address space,
> propagation is always permitted. Otherwise, IPC occurs unpropagated.". The
> implementation actually implements that behavior, and it seems to be an
> unwanted side-effect that local IDs don't work there and that the
> implementation then continues with the IPC, but unpropagated.

I should've said "... that the IPC operation succeeded as expected by the
caller when it did not", i.e. my critique was toward the spec rather than
the implementation.

It would be interesting to learn the rationale for this behaviour. From a
naive reading of the way IPC is specified in L4.X2, propagation feels like a
hack (i.e. the designers having added a new behaviour to the IPC syscall and
a new TCR, but keeping the existing set of error conditions so as to re-use
existing code without modification) -- but that sounds implausible given how
it fits with clans-and-chiefs, which (IIRC) has been around for quite a
while.

> An ASSERT catching local IDs might be more appropriate in this case.
>

Agreed. Even if non-propagation with "p" set were reported as an error
status, there don't seem to be any obvious things that the sender could do
to recover besides logging the unexpected condition and general attempts to
return to a known-good state.

On the other hand, delivering a "not quite propagated" message to the
recipient may cause all sorts of confusion in operations where the sender's
ID is significant. On the third hand, a case can be made that regardless of
whether delivery occurs, the system as a whole is already behaving in an
undefined manner and that lossage of some kind is bound to occur. (Side
effects of such a misdelivery would presumably be limited to things that are
identified by the ID of the propagator, and so wouldn't be devastating by
themselves.)

--
Kalle A. Sandstro"m ksandstr@...
746B 4B14: BFB5 6D3B 0758 CFBE 11F9 DF41 4C28 67FB 746B 4B14
void *truth = &truth; http://ksandstr.iki.fi/

RE: [PATCH] fix improper return of local sender TID in propagated IPC

2009-04-08T05:24:24Z

Hello Kalle,

Thanks for the patch. It makes sense to me, and I have committed it to the repository. Apparently the local ID logic doesn't handle the propagation case very well.

> As requiring that the VirtualSender TCR always contain a global TID
> when propagation is specified in the message tag, I'd like to recommend
> that the
> L4.X2 spec be revised accordingly.

Hmm. I actually wouldn't want change the spec. The implementation follows the spec, not vice versa. And just because the implementation doesn't handle every (corner) case or contains bugs, I don't see any conceptual reason why local IDs shouldn't be used when propagating messages.

> If it matters for a short patch like this, the attached changeset is
> licensed under the two-clause BSD license as given at the start of the
> source file it modifies.

Yes, that actually matters. BSD license is fine, though. Thanks.

> [2] IMO, silently disabling propagation is the wrong thing to do as it
> tells
> the sender that the IPC operation succeeded as specified when it
> did
> not. This behaviour also diverges from that of Pistachio 0.4 .

That's debatable. The spec says: "If originator thread and current sender, or
current sender and receiver reside in the same address space, propagation is always permitted.
Otherwise, IPC occurs unpropagated.". The implementation actually implements that behavior, and it seems to be an unwanted side-effect that local IDs don't work there and that the implementation then continues with the IPC, but unpropagated. An ASSERT catching local IDs might be more appropriate in this case.

Best,
-Jan

--
Jan Stoess
System Architecture Group
University of Karlsruhe
Phone: +49 (721) 608-4056
Fax: +49 (721) 608-7664
eMail: stoess@...

[PATCH] fix improper return of local sender TID in propagated IPC

2009-03-28T15:36:50Z

The attached patch[1] fixes a problem where a recipient may get the thread
ID of a propagating thread rather than the propagator's VirtualSender TCR.

This misbehaviour was observed when the propagator and the recipient were in
one address space and the original sender was in another, and the propagator
went through a blocking send phase to deliver the message. The issue was
that at the end of the last function in kernel/src/api/v4/ipc.cc,
from_tcb->get_global_id() was used interchangeably with
current->get_partner() when in the propagating case they almost certainly
refer to distinct threads.

As for why this was only observed in a blocking-send case and not in the
non-blocking case, I have no idea. I only drilled down from the return value
observed by the recipient, and correcting it seemed the right thing to do.

The changeset also enforces, using an ASSERT(), the notion that the virtual
sender in IPC propagation is always identified by global TID. This is
supported by lines 313-329 in kernel/src/api/v4/ipc.cc, which silently
disables[2] propagation if VirtualSender is not a global TID (as a local TID
cannot be equal to the result of get_global_id() of the virtual sender's
tcb_t).

As requiring that the VirtualSender TCR always contain a global TID when
propagation is specified in the message tag, I'd like to recommend that the
L4.X2 spec be revised accordingly.

If it matters for a short patch like this, the attached changeset is
licensed under the two-clause BSD license as given at the start of the
source file it modifies.

[1] hg bundle -- I hope this is the correct format

[2] IMO, silently disabling propagation is the wrong thing to do as it tells
the sender that the IPC operation succeeded as specified when it did
not. This behaviour also diverges from that of Pistachio 0.4 .

--
Kalle A. Sandstro"m ksandstr@...
746B 4B14: BFB5 6D3B 0758 CFBE 11F9 DF41 4C28 67FB 746B 4B14
void *truth = &truth; http://ksandstr.iki.fi/

pistachio-propagate-partner-properly.hg (1K) Download Attachment

How about a 0.5 release?

2009-03-25T08:19:05Z

The 0.4 release has become very old. Old enough to not compile with a modern
version of G++, old enough for the compiler it _can_ be compiled with to not
ship in the two most recent major releases of Debian GNU/Linux. That is
quite old indeed.

So my question is: are there plans to do a 0.5 release of L4Ka::Pistachio?

To provide a bit of context, over the past three or so years I've been
hobbyhorsing together an Unix-like operating system personality on top of
the Pistachio microkernel. (It's available under the GPLv3 at
http://muix.ath.cx for those interested.) For now, it has been written
against the 0.4 headers and quirks[1], but that revision has become
virtually unusable by itself due to reasons mentioned above, and others.

Thus I couldn't release a 0.1 of µiX even if I wanted to: it'd be
unbuildable against the (soon five years old) Pistachio 0.4 simply because
Pistachio can't be compiled as found in the 0.4 tarball on l4ka.org . The
unsatisfactory alternatives would involve taking a development version from
the Mercurial tree and tarballing it up for distribution as a "companion to
µiX 0.1", or developing a large and ultimately pointless patchset against
Pistachio 0.4 to make it compile with g++ 4.3 .

If there are significant issues featurewise with regard to releasing 0.5 as
a snapshot of the Mercurial tree[2], then are these issues large enough to
not release a 0.5 given the problems in retaining 0.4 as the most recent
formal release?

[1] such as the extra parentheses in a caching hint #define, and how the
header file that defines L4_BootRec_t isn't copied into the install
directory.

[2] I noted paths in the scheduling code marked as "hole", and a major
problem in kickstart failing to avoid stepping on boot modules when
relocating sigma0, the root task and so forth.

--
Kalle A. Sandstro"m ksandstr@...
746B 4B14: BFB5 6D3B 0758 CFBE 11F9 DF41 4C28 67FB 746B 4B14
void *truth = &truth; http://ksandstr.iki.fi/

Re: Fastpath on x32: Every single cycle

2009-03-08T03:11:59Z

*bump*
Any comments are appreciated!

----- Original Message -----
From: "Moritz Kroll" <Moritz.Kroll@...>
To: <l4ka@...>
Sent: Monday, February 23, 2009 9:23 PM
Subject: Fastpath on x32: Every single cycle

>I don't understand, why on the receive side MR_1 and MR_2 are loaded into
>registers (EBX and EBP). In many cases they may be unused and even if they
>would be used, they could easily be fetched by the user (especially as the
>UTCB pointer is already available in EDI).
> You may argue, that MR_0 is loaded from the UTCB anyway, so MR_1 and MR_2
> are already in the cache. But why has MR_0 to be loaded, if it is
> initially in ESI?
>
> Here's a suggestion what can be done (without small spaces) to keep ESI
> untouched (l4ka-pistachio-38b2e96fc5a6\kernel\src\glue\v4-x86\x32\trap.S):
> 1. Use "test $0x3f, %esi" instead of "and $0x3f, %esi; test %esi, %esi"
> (one byte more, but doesn't change ESI)
> 2. Use EDX instead of ESI for "dest" starting from label 3
> 3. Move "popl %ecx" to label 7 (should be unaffected by page table switch,
> makes ECX free to use)
> 4. Use "movl %cr3, %ecx; cmpl %eax, %ecx" instead of "movl %cr3, %edx;
> cmpl %eax, %edx" (don't use EDX anymore)
> 5. Remove all "load MRs" lines (9 bytes and three memory accesses less)
>
> If you can also spare the copy of MR_0 to the destination UTCB, I think
> this would also save you one cache line, if no untyped words are
> transmitted. According to the L4 X.2 reference manual MR_0 is not mapped
> to memory, anyway.
>
> What do you think, does this make sense?
> It would require a change of the (not stable) specification, but I don't
> see any reason for MR_1 and MR_2 to be received in registers on x32.
> Btw, why are MR_1 and MR_2 stored in the UTCB again in L4_Ipc, when they
> have just been loaded from there?
>
> Best regards
> Moritz

Re: StringItem length

2009-03-08T03:11:17Z

*bump*
Any comments are appreciated.

----- Original Message -----
From: "Moritz Kroll" <Moritz.Kroll@...>
To: <l4ka@...>
Sent: Monday, February 23, 2009 4:12 PM
Subject: StringItem length

> The "current" L4 X.2 reference manual (2006-11-17) states on page 56
> (section 5.4 StringItem) that the "maximum string length is 4 M bytes,
> even if the according field is 54 bits wide on 64-bit processors".
> Two questions:
>
> 1. How do you encode a string size of 4 MB on 32-bit?
> As far as I see it's not possible (only 22 length bits) and there is no
> implicit +1 used in the kernel source code. If this is intended (probably
> to allow zero-length strings (why?)), the manual should be more clear on
> the maximum size ((4 M - 1) bytes).
>
> 2. Who enforces the maximum size on 64-bit (x64)?
> For intra-space string copies I didn't find any reason why e.g. a 10 GB
> copy shouldn't work. For an inter-space string copy still even any 1 GB
> copy should work, as the copy area has a size of 2 GB. I have no idea,
> what will happen to larger copies, though. I guess an unhandled kernel
> pagefault when the memcpy reaches the end of the copy area?
>
> Best regards
> Moritz

Fastpath on x32: Every single cycle

2009-02-23T12:23:25Z

I don't understand, why on the receive side MR_1 and MR_2 are loaded into
registers (EBX and EBP). In many cases they may be unused and even if they
would be used, they could easily be fetched by the user (especially as the
UTCB pointer is already available in EDI).
You may argue, that MR_0 is loaded from the UTCB anyway, so MR_1 and MR_2
are already in the cache. But why has MR_0 to be loaded, if it is initially
in ESI?

Here's a suggestion what can be done (without small spaces) to keep ESI
untouched (l4ka-pistachio-38b2e96fc5a6\kernel\src\glue\v4-x86\x32\trap.S):
1. Use "test $0x3f, %esi" instead of "and $0x3f, %esi; test %esi, %esi" (one
byte more, but doesn't change ESI)
2. Use EDX instead of ESI for "dest" starting from label 3
3. Move "popl %ecx" to label 7 (should be unaffected by page table switch,
makes ECX free to use)
4. Use "movl %cr3, %ecx; cmpl %eax, %ecx" instead of "movl %cr3, %edx; cmpl
%eax, %edx" (don't use EDX anymore)
5. Remove all "load MRs" lines (9 bytes and three memory accesses less)

If you can also spare the copy of MR_0 to the destination UTCB, I think this
would also save you one cache line, if no untyped words are transmitted.
According to the L4 X.2 reference manual MR_0 is not mapped to memory,
anyway.

What do you think, does this make sense?
It would require a change of the (not stable) specification, but I don't see
any reason for MR_1 and MR_2 to be received in registers on x32.
Btw, why are MR_1 and MR_2 stored in the UTCB again in L4_Ipc, when they
have just been loaded from there?

Best regards
Moritz

StringItem length

2009-02-23T07:12:53Z

The "current" L4 X.2 reference manual (2006-11-17) states on page 56
(section 5.4 StringItem) that the "maximum string length is 4 M bytes, even
if the according field is 54 bits wide on 64-bit processors".
Two questions:

1. How do you encode a string size of 4 MB on 32-bit?
As far as I see it's not possible (only 22 length bits) and there is no
implicit +1 used in the kernel source code. If this is intended (probably to
allow zero-length strings (why?)), the manual should be more clear on the
maximum size ((4 M - 1) bytes).

2. Who enforces the maximum size on 64-bit (x64)?
For intra-space string copies I didn't find any reason why e.g. a 10 GB copy
shouldn't work. For an inter-space string copy still even any 1 GB copy
should work, as the copy area has a size of 2 GB. I have no idea, what will
happen to larger copies, though. I guess an unhandled kernel pagefault when
the memcpy reaches the end of the copy area?

Best regards
Moritz

RE: Double allocation of UTCB__MAPPING in Pistachio

2009-02-23T02:09:26Z

> I guess, the first mapping should be removed. Am I right?

I think you're right. Seems as if this had been introduced when the implementations for IA32 and AMD64 were merged. I removed the first mapping.

Thanks for the hint,
Philipp

Double allocation of UTCB__MAPPING in Pistachio

2009-02-22T09:04:28Z

This looks like a double commit in
l4ka-pistachio-38b2e96fc5a6/kernel/src/glue/v4-x86/space.cc:703:

/* MYUTCB mapping
* allocate a full page for all myutcb pointers.
* access must be performed via gs:0, when setting up the gdt
* each processor gets a full cache line to avoid bouncing
* page is user-writable and global
*/
EXTERN_KMEM_GROUP(kmem_misc);
add_mapping((addr_t)UTCB_MAPPING,
virt_to_phys(kmem.alloc(kmem_misc, X86_PAGE_SIZE)),
pgent_t::size_4k, true, false, true);

EXTERN_KMEM_GROUP(kmem_misc);
utcb_page = kmem.alloc(kmem_misc, X86_PAGE_SIZE);
ASSERT(utcb_page);
add_mapping((addr_t)UTCB_MAPPING, virt_to_phys(utcb_page),
pgent_t::size_4k, true, false, true);

I guess, the first mapping should be removed. Am I right?

Best regards
Moritz Kroll

Re: Compiling L4Ka::Pistachio with SMP support

2009-01-14T11:06:23Z

On Wed, Jan 14, 2009 at 6:54 PM, Jan Stoess <stoess@...> wrote:
> Have you tried enabling APIC support? This is a prerequisite for SMP, although the cml2 config system doesn't enforce it.

Indeed it builds correctly with APIC enabled. Thanks for the heads
up, I was hoping it was just something silly that i missed!

>
> -Jan
> --
> Jan Stoess
> System Architecture Group
> University of Karlsruhe
> Phone: +49 (721) 608-4056
> Fax: +49 (721) 608-7664
> eMail: stoess@...
>
>

RE: Compiling L4Ka::Pistachio with SMP support

2009-01-14T10:54:46Z

Have you tried enabling APIC support? This is a prerequisite for SMP, although the cml2 config system doesn't enforce it.

-Jan
--
Jan Stoess
System Architecture Group
University of Karlsruhe
Phone: +49 (721) 608-4056
Fax: +49 (721) 608-7664
eMail: stoess@...

Compiling L4Ka::Pistachio with SMP support

2009-01-14T10:02:23Z

I had no problems cloning the Pistachio repository and compiling the
default kernel, but I'm having an issue whenever I enable SMP support
in the kernel. The specific error is in interrupt.cc with an
undeclared 'is_pending'.

/home/jnwhiteh/l4ka-pistachio/kernel/src/api/v4/interrupt.cc: In function `void
migrate_interrupt_end(tcb_t*)':
/home/jnwhiteh/l4ka-pistachio/kernel/src/api/v4/interrupt.cc:411: error: `
is_pending' undeclared (first use this function)
/home/jnwhiteh/l4ka-pistachio/kernel/src/api/v4/interrupt.cc:411: error: (Each
undeclared identifier is reported only once for each function it appears
in.)
make[1]: *** [src/api/v4/interrupt.o] Error 1
make[1]: Leaving directory `/home/jnwhiteh/l4ka-pistachio/x86-kernel-build'
make: *** [all] Error 2

The full compile log can be found at http://l4ka.pastey.net/106311.
Has anyone run into this error or is there a known fix for the issue?

Jim Whitehead
University of Oxford
Computing Laboratory

CAmkES: component-based development for L4

2008-12-08T22:36:59Z

NICTA is happy to announce the first open source release of CAmkES.

CAmkES provides an easier way to develop OKL4-based software and
systems.

It is a component-based software development and runtime framework
for OKL4, allowing microkernel-based systems to be modelled and built
as a set of interacting software components. These software
components have explicit interaction interfaces and a system design
that explicitly details the connections between the components.

The development framework provides:
* a language to describe component interfaces, components, and whole
component-based systems;
* a tool that processes these descriptions to combine programmer-
provided component code with generated scaffolding and glue code to
build a complete, bootable, system image;
* full integration in the OKL4 environment and build system.

Find out more about CAmkES, download it, and try it out here:

http://www.ertos.nicta.com.au/software/camkes/

On behalf of the CAmkES team,

Ihor

--
Ihor Kuz
Senior Researcher

NICTA | Locked Bag 6016 | UNSW, Sydney NSW 1466
T + 61 2 8306 0582 | F +61 2 8306 0406
www.nicta.com.au l ihor.kuz@...

Re: How does pistachio deal with the priority inversion?

2008-10-16T06:20:02Z

> > The woken thread will be dispatched no later than on the next timer
> > interrupt (see above case 2). It might be run earlier (case 1 above), but
> > then it can run for a complete timeslice (which is typically much longer
> > than the timer period).

> Yeah, that's what i want. Thanks a lot. What's more, does time donation (you
> said which is typically much longer than the timer period) happened here? if
> so, could you explain it (time donation) a little more for me?

Typical timeslices are 10ms (on x86), the timer interrupt fires every 1000us
(microseconds), i.e., every 1ms or 10 times per timeslice. That's what I meant
with timeslices being much longer that the timer period.

Timeslice donation always occurs when we switch threads behind the scheduler's
back, i.e., during IPC. The kernel scheduler maintains a timeslice_tcb, which
is a pointer to the thread on whose timeslice we run (and on which we base our
decisions as to whether the current timeslice is over or not), but this is
updated only in schedule(), end_of_timeslice(), and preempt_thread(), none of
which is called during IPC. There we just use switch_to() ...

If the low prio thread B sends an IPC to the high prio thread A, A will be
woken and immediately dispatched (bypassing the scheduler) and continue
execution on B's timeslice until the timeslice expires (or A yields or blocks).
At the end of B's timeslice, the scheduler will be invoked and probably select
A to run. This time, however, also the timeslice_tcb is updated to point to A,
so that A will run on its own timeslice.

> > The L4 kernel is not preemptible (interrupts are disabled while inside the
> > kernel) except during string IPC and possibly during the recursive unmap
> > operation: Here we explicitly enable interrupts to reduce IRQ handler
> > latency. All other code paths through the kernel are rather short, so that
> > making the kernel preemptible would not pay.

> I known that for IA32 when entering kernel space, it's must through the int
> gate(or call gate) whether interrupt or system call. And the after through
> the gate ,all interrupts will be disabled(set IF flag). But, I didn't find
> where these interrupts be enabled again?. Enabled when the interrupted
> thread(or any thread?) return back to user level?

Yes, interrupts are either implicitly turned on when leaving the kernel via
iret (return from interrupt) or explicitly via sti (set interrupt flag, thus
*enabling* interrupts) just before leaving the kernel via sysexit/sysret on
the IPC path.

Regards,
Raphael

RE: How does pistachio deal with the priority inversion?

2008-10-15T22:50:31Z

> The woken thread will
> be dispatched no later than on the next timer interrupt (see above case 2).
> It might be run earlier (case 1 above), but then it can run for a complete
> timeslice (which is typically much longer than the timer period).

Yeah,that's what i want. Thanks a lot.
What's more,does time donation(you said which is typically much longer than the timer period) happened here?
if so ,could you explain it(time donation) a little more for me?

> The L4 kernel is not preemptible (interrupts are disabled while inside
> the kernel) except during string IPC and possibly during the recursive
> unmap operation: Here we explicitly enable interrupts to reduce IRQ handler
> latency.
> All other code paths through the kernel are rather short, so that making
> the kernel preemptible would not pay.

I known that for IA32 when entering kernel space, it's must through the int gate(or call gate) whether interrupt or system call.
And the after through the gate ,all interrupts will be disabled(set IF flag).
But, I didn't find where these interrupts be enabled again?. Enabled when the interrupted thread(or any thread?) return back to user level?

Thank you for your time!

---
Best regards

Bo Liu

> Date: Wed, 15 Oct 2008 13:32:04 +0200
> From: neider@...
> To: bo-liu@...
> CC: l4ka@...
> Subject: Re: How does pistachio deal with the priority inversion?
>
> > > IPC won't start at all as B will never run.
> > So thread A will Blocked for a very long time untill B gets to run?
>
> Yes. However, you can use timeouts in A's IPC operation to avoid/recover
> from such situations.
>
> > > L4 leaves this problem to the OS on top, it does not deal with
> > > starvation/priority inversion at all. Scheduling on L4 is still not
> > > solved satisfactorily.
> >
> > NOw, I am messed by L4's schedule mechanism. It' based on static priority and
> > timeslice. When a very high priority thread being wakeup. It will be
> > scheduled untill a time interrupt happen?
>
> How can a high priority thread wake up?
> 1. receive IPC
> 2. timeout, detected at some timer interrupt
>
> In the first case, either a user thread or an interrupt thread explicitly
> calls the high priority thread, immediately scheduling it for execution.
>
> In the second case, I assume, the scheduler is invoked after having detected
> that a (high priority) thread has reached a timeout.
> But even if I am wrong and we do not immediately schedule the timed-out thread,
> it will be scheduled after the end of the current timeslice (given no thread
> with a still higher priority becomes ready in the meantime).
>
> I am not sure about the 'until' in your question: The woken thread will
> be dispatched no later than on the next timer interrupt (see above case 2).
> It might be run earlier (case 1 above), but then it can run for a complete
> timeslice (which is typically much longer than the timer period).
>
> > And does Pistachio support kernel preempt like the linux kernel 2.6?
>
> The L4 kernel is not preemptible (interrupts are disabled while inside
> the kernel) except during string IPC and possibly during the recursive
> unmap operation: Here we explicitly enable interrupts to reduce IRQ handler
> latency.
> All other code paths through the kernel are rather short, so that making
> the kernel preemptible would not pay.
>
> Hope that helped,
> Raphael
>

Get news, entertainment and everything you care about at Live.com. Check it out!

Re: How does pistachio deal with the priority inversion?

2008-10-15T04:32:04Z

> > IPC won't start at all as B will never run.
> So thread A will Blocked for a very long time untill B gets to run?

Yes. However, you can use timeouts in A's IPC operation to avoid/recover
from such situations.

> > L4 leaves this problem to the OS on top, it does not deal with
> > starvation/priority inversion at all. Scheduling on L4 is still not
> > solved satisfactorily.
>
> NOw, I am messed by L4's schedule mechanism. It' based on static priority and
> timeslice. When a very high priority thread being wakeup. It will be
> scheduled untill a time interrupt happen?

How can a high priority thread wake up?
1. receive IPC
2. timeout, detected at some timer interrupt

In the first case, either a user thread or an interrupt thread explicitly
calls the high priority thread, immediately scheduling it for execution.

In the second case, I assume, the scheduler is invoked after having detected
that a (high priority) thread has reached a timeout.
But even if I am wrong and we do not immediately schedule the timed-out thread,
it will be scheduled after the end of the current timeslice (given no thread
with a still higher priority becomes ready in the meantime).

I am not sure about the 'until' in your question: The woken thread will
be dispatched no later than on the next timer interrupt (see above case 2).
It might be run earlier (case 1 above), but then it can run for a complete
timeslice (which is typically much longer than the timer period).

> And does Pistachio support kernel preempt like the linux kernel 2.6?

The L4 kernel is not preemptible (interrupts are disabled while inside
the kernel) except during string IPC and possibly during the recursive
unmap operation: Here we explicitly enable interrupts to reduce IRQ handler
latency.
All other code paths through the kernel are rather short, so that making
the kernel preemptible would not pay.

Hope that helped,
Raphael

RE: How does pistachio deal with the priority inversion?

2008-10-15T02:41:46Z

>
> IPC won't start at all as B will never run.
>
So thread A will Blocked for a very long time untill B gets to run?

>
> L4 leaves this problem to the OS on top, it does not deal with
> starvation/priority inversion at all. Scheduling on L4 is still
> not solved satisfactorily.

NOw, I am messed by L4's schedule mechanism. It' based on static priority and timeslice.
When a very high priority thread being wakeup. It will be scheduled untill a time interrupt happen?
And does Pistachio support kernel preempt like the linux kernel 2.6?

Thanks a lot!

---
Best regards

Bo Liu

Discover the new Windows Vista Learn more!

Re: How does pistachio deal with the priority inversion?

2008-10-15T02:11:53Z

Hi Bob,

> When a high priority thread A perform IPC receive from B, but B is not
> in polling state. So A blocked. Before B can perform the IPC that
> unblocks A, a third thread C with priority between A and B becomes
> ready,preempts B and runs. If lots of such thread C, IPC will be very
> slow.

IPC won't start at all as B will never run.

> How pistachio deal with this? I read some code,it seems no special
> process. Thanks!

L4 leaves this problem to the OS on top, it does not deal with
starvation/priority inversion at all. Scheduling on L4 is still
not solved satisfactorily.

Regards,
Raphael

How does pistachio deal with the priority inversion?

2008-10-15T00:25:15Z

Hi, All. Question again.
When a high priority thread A perform IPC receive from B, but B is not in polling state. So A blocked.
Before B can perform the IPC that unblocks A, a third thread C with priority
between A and B becomes ready,preempts B and runs. If lots of such thread C,
IPC will be very slow.
How pistachio deal with this? I read some code,it seems no special process.
Thanks!

---
Best regards

Bo Liu

_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE

RE: only kernel can access copy_area ?

2008-10-14T02:13:01Z

Thank you Raphael. It's so clearly!
It seems easy and simple. But I couldn't understand it before.
I think i need introspection and think more.

---
Best regards

Bo Liu

> Date: Tue, 14 Oct 2008 10:29:35 +0200
> From: neider@...
> To: bo-liu@...
> CC: l4ka@...
> Subject: Re: only kernel can access copy_area ?
>
> On 2008-10-14 at 00:33, lion wrote:
> >
> > Still uncleanly about that...
> > About the copy_area's implemention.
> >
> > > About the copy_area,
>
> The copy area is a temporary mapping of a part of B's address space (the
> destination of the string transfer) into the kernel region in order to
> make B's memory accessible while A's address space is active (otherwise
> there would be no name, i.e., virtual address in A's address space, to
> access that memory).
> In principle, both A and B could access the mapping area: it is not protected
> by means of page protections (the page is user accessible due to its page
> table entry being copied from B and the page being user accessible there) nor
> by means of segmentation (on x86, due to L4 not using segments for protection
> at all except with small spaces).
>
> But: The copy area is unmapped
> (a) before A returns to user mode after the IPC and/or
> (b) at the next thread switch (whichever occurs first),
> so neither A nor B (nor any other thread at user level) has a chance of
> actually accessing B's memory by means of the copy area.
>
> Now back to answering your questions:
> > > when A sends a message to B, only kernel A and user B can access
> > > the copy_area. But user A can not. Is these correct ? And why ?
> That's not correct. Theoretically, user A, user B, kernel A, and kernel B
> can access the copy area, but due to kernel guarantees as to which thread
> actually runs, only kernel A gets the chance to do so.
> The `why' should have been answered above.
>
> > > In my opinion, the page table of A's copy_area is copyed from B which
> > > is user accessiable.
> > > So,user A can access the copy_area. Is that right?
> Again: Yes, but only in theory as user A never runs while the mapping exists.
>
> Hoping that helped to clear things up a bit,
> Raphael
>

Explore the seven wonders of the world Learn more!

Re: only kernel can access copy_area ?

2008-10-14T01:29:35Z

On 2008-10-14 at 00:33, lion wrote:
>
> Still uncleanly about that...
> About the copy_area's implemention.
>
> > About the copy_area,

The copy area is a temporary mapping of a part of B's address space (the
destination of the string transfer) into the kernel region in order to
make B's memory accessible while A's address space is active (otherwise
there would be no name, i.e., virtual address in A's address space, to
access that memory).
In principle, both A and B could access the mapping area: it is not protected
by means of page protections (the page is user accessible due to its page
table entry being copied from B and the page being user accessible there) nor
by means of segmentation (on x86, due to L4 not using segments for protection
at all except with small spaces).

But: The copy area is unmapped
(a) before A returns to user mode after the IPC and/or
(b) at the next thread switch (whichever occurs first),
so neither A nor B (nor any other thread at user level) has a chance of
actually accessing B's memory by means of the copy area.

Now back to answering your questions:
> > when A sends a message to B, only kernel A and user B can access
> > the copy_area. But user A can not. Is these correct ? And why ?
That's not correct. Theoretically, user A, user B, kernel A, and kernel B
can access the copy area, but due to kernel guarantees as to which thread
actually runs, only kernel A gets the chance to do so.
The `why' should have been answered above.

> > In my opinion, the page table of A's copy_area is copyed from B which
> > is user accessiable.
> > So,user A can access the copy_area. Is that right?
Again: Yes, but only in theory as user A never runs while the mapping exists.

Hoping that helped to clear things up a bit,
Raphael

Re: only kernel can access copy_area ?

2008-10-14T00:32:55Z

Still uncleanly about that...
About the copy_area's implemention.

lion wrote:

Hi, all
Thank you for these days' help.
Now, I am learning about ipc. And have a question again. Sorry for troubling you!

About the copy_area,when A sends a message to B, only kernel A and user B can access
the copy_area. But user A can not. Is these correct ? And why ?
In my opinion, the page table of A's copy_area is copyed from B which is user accessiable.
So,user A can access the copy_area. Is that right?

Thank you
---Best regardsBo Liu
_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx

RE: What's the difference between Quantum and Timeslice ?

2008-09-18T18:43:29Z

Thanks Raphael.

I have got there differences now.

An addition question. In handle_timer_interrupt(schedule.cc),
why useing (get_prio_queue(current)->current_timeslice -= get_timer_tick_length()) <= 0 to determine
whether end of a thread's timeslice?
Why not just use "(tcb->current_timeslice -= get_timer_tick_length) <= 0".

So as in end_of_timeslice():
tcb->current_timeslice = prio_queue->current_timeslice + tcb->timeslice_length;
prio_queue->current_timeslice = prio_queue->get(get_priority (tcb))->current_timeslice;

Why there must a prio_queue->current_timeslice but not just use tcb->timeslice ?

Thank you for you time!

---
Best regards

Bo Liu

> Date: Thu, 18 Sep 2008 11:04:12 +0200
> From: neider@...
> To: bo-liu@...; l4ka@...
> Subject: Re: What's the difference between Quantum and Timeslice ?
>
> Hi Bob,
>
>> What's the difference between Quantum and Timeslice ?
>> Timeslice is used for thread scheduler. Then Quantum used for what ?
>
> A new timeslice is allocated every time a thread is scheduled and (only)
> serves to implement round-robin-scheduling: after at most "timeslice"
> time, the thread is preempted and another thread can be scheduled. The
> preempted thread may be scheduled again.
>
> The (total) quantum was intended to limit the total time the thread may
> spend executing on any CPU. It is decreased every time a timer interrupt
> occurs (just like timeslices are, see schedule.cc,
> handle_timer_interrupt()), but never reset automatically (only via a
> schedule syscall). Once a thread runs out of time (no quantum left), it
> will not be scheduled again (a preemption IPC should be sent to its
> scheduler, but that's disabled due to major problems, see scheduler.cc,
> total_quantum_expired()).
>
> In short, the timeslice determines for how long a thread can
> continuously occupy a CPU before being preempted, the quantum limits the
> total time the thread may spend on the CPUs accumulated over all
> occasions the thread was scheduled.
>
> Regards,
> Raphael

_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE

Re: What's the difference between Quantum and Timeslice ?

2008-09-18T02:04:12Z

Hi Bob,

> What's the difference between Quantum and Timeslice ?
> Timeslice is used for thread scheduler. Then Quantum used for what ?

A new timeslice is allocated every time a thread is scheduled and (only)
serves to implement round-robin-scheduling: after at most "timeslice"
time, the thread is preempted and another thread can be scheduled. The
preempted thread may be scheduled again.

The (total) quantum was intended to limit the total time the thread may
spend executing on any CPU. It is decreased every time a timer interrupt
occurs (just like timeslices are, see schedule.cc,
handle_timer_interrupt()), but never reset automatically (only via a
schedule syscall). Once a thread runs out of time (no quantum left), it
will not be scheduled again (a preemption IPC should be sent to its
scheduler, but that's disabled due to major problems, see scheduler.cc,
total_quantum_expired()).

In short, the timeslice determines for how long a thread can
continuously occupy a CPU before being preempted, the quantum limits the
total time the thread may spend on the CPUs accumulated over all
occasions the thread was scheduled.

Regards,
Raphael

What's the difference between Quantum and Timeslice ?

2008-09-18T01:35:37Z

Hi, All

What's the difference between Quantum and Timeslice ?
Timeslice is used for thread scheduler. Then Quantum used for what ?

Thanks,

---
Best regards

Bo Liu

_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE

only kernel can access copy_area ?

2008-09-16T03:01:25Z

Hi, all
     Thank you for these days' help.
     Now, I am learning about ipc. And have a question again. Sorry for troubling you!

     About the copy_area,when A sends a message to B, only kernel A and user B can access
the copy_area. But user A can not. Is these correct ? And why ?
     In my opinion, the page table of A's copy_area is copyed from B whick is user accessiable.
So,user A can access the copy_area. Is that right?
     Thank you


---
Best regards

Bo Liu

Get news, entertainment and everything you care about at Live.com. Check it out!

Re: How to access VRAM physical address on L4 ?

2008-09-11T05:38:25Z

> All pager's has to "ask" sigma0 for the page. Whether it becomeing the
> performance bottleneck.

On system startup, user-level pager(s) should request the memory they need from sigma0. Thus, once the system is completely up and running, sigma0 has no pages left to give out, and there should be no reason for user-level pagers or other threads to interact with sigma0 any more.
Consequently, the performance of sigma0 is no longer important once the other pagers are running and have acquired their memory.

Cheers,
Philipp

RE: How to access VRAM physical address on L4 ?

2008-09-10T18:12:31Z

Thank you, Philipp. It's clearly.
Another little question.
All pager's has to "ask" sigma0 for the page. Whether it becomeing the performance bottleneck.

---
Best regards

Bo Liu

>
> Your pager has to "ask" sigma0 for the page(s) it needs, and it has to set its receive window accordingly. The receive window allows the pager to specify to where the fpage that sigma0 returns is mapped.
> Convenience functions for requesting memory from sigma0 can be found in user/include/l4/sigma0.h
>
> Hope this helps,
> Philipp

Explore the seven wonders of the world Learn more!

Re: How to access VRAM physical address on L4 ?

2008-09-10T09:36:12Z

> Our own pager not sigma0 can do these map?

Your pager has to "ask" sigma0 for the page(s) it needs, and it has to set its receive window accordingly. The receive window allows the pager to specify to where the fpage that sigma0 returns is mapped.
Convenience functions for requesting memory from sigma0 can be found in user/include/l4/sigma0.h

Hope this helps,
Philipp