Various questions

Espen Skoglund esk at
Tue Nov 9 15:20:17 CET 2004

[Mattia Belletti]
> Hi all - I have some questions; I hope they have not already been posed!

> - I'm running a bare qemu + pistachio 0.4, and its kickstart +
> sigma0, with a little root server of my own, on a IA32
> architecture. I ask for bootinfo location, and I find it's 0x1000
> (that's where kickstart puts it, so it's ok). However, when I try
> accessing it, I obviously pagefault, but sigma0 refuses to give me
> that page. Anyway, if I _force_ it it to do (I've tweaked by hand
> source code), everything works fine - in fact the bootinfo is there,
> and it is correct. Did I get something wrong?

When sigma0 sees that some memory is bootloader specific, architecture
specific, etc., it assumes that there is some special semantics or
contents within this memory.  Such memory must be requested
specifically using, e.g., L4_Sigma0_GetPage().

> - Little note: looking kickstart, I found this, around
> user/util/kickstart/

>      if (use_bootinfo)
>      {
>          // Allocate and initialize a bootinfo structure.
>          bi = init_bootinfo (&kip);
>          rec = (L4_BootRec_t *) ((L4_Word_t) bi + bi->size);

>          if (bi)
>              // Record MBI modules
>              rec = record_bootinfo_modules (bi, rec);
>          else
>              use_bootinfo = false;
>      }

> (I'm referring to CVS version, If I remember well 0.4 version was
> exactly the same). The "rec = stuff" isn't wrong? If "bi" is set to
> NULL by the init_bootinfo (in case of OOM, if I remember well), this
> segfaults - well, don't know what it does exactly, since there's
> still no kernel around, and I don't remember IA32 defaults ;D

No, it's not entirely wrong.  If bi == NULL then you simply set
use_bootinfo to false.  You also de-reference the NULL pointer, but
that's all fine since we're running on physical memory (i.e., no page
faults).  Of course, this assumes that the null page is actually
present in the system---which might be a bad thing to assume. ;-)

> - Looking L4 specs (even the latest - by the way, how come the sources
> theirselves aren't published? I would have found it useful when I did
> those searches about sigma0 ;D), I have found no satisfying explanation
> about the kinds of memory descriptors L4 knows about. That is,
> UndefinedMemoryType, BootLoaderSpecificMemoryType,
> ArchitectureSpecificMemoryType are obvious, but what are the differences
> between ConventionalMemoryType and SharedMemoryType? What between
> ReservedMemoryType and DedicatedMemoryType? What are their exact
> meanings? Not that I absolutely need to work this out now, but I would
> like to know this better! :-)

ConventionalMemoryType - Regular memory

SharedMemoryType - Memory that is available to all users (i.e.,
everyone can request it from sigma0).  This is sometimes used for,
e.g., the screen memory (but only for debugging purposes, never in a
production system).

ReservedMemoryType - Reserved by kernel.

DedicatedMemoryType - Not avaialble to user (indicates that it is not
used by kernel either).  This could for example be BIOS specific

> - Last: what purpose sigma1 has? I remember reading something about it
> in the papers about transparent checkouts of kernel state, and stuff
> like that...

Yes.  Sigma1 could act as a pager for the kernel.  This is not
currently implemented, though.


More information about the l4-hackers mailing list