Nova multiboot v.1 flags == 0 ???

[Paul Dufresne]

I think I have a problem with Nova multiboot specification.

In https://github.com/udosteinberg/NOVA/blob/master/src/start.S :

/*
* Multiboot Header
*/
__boot_header: .long 0x1badb002
.long 0x0
.long -0x1badb002

This is multiboot v.1 (current version is 2).

3.1.1 The layout of Multiboot header


The layout of the Multiboot header must be as follows:

Offset  TypeField Name Note
0   u32 magic  required
4   u32 flags  required
8   u32 checksum   required
12  u32 header_addrif flags[16] is set
16  u32 load_addr  if flags[16] is set
20  u32 load_end_addr  if flags[16] is set
24  u32 bss_end_addr   if flags[16] is set
28  u32 entry_addr if flags[16] is set
32  u32 mode_type  if flags[2] is set
36  u32 width  if flags[2] is set
40  u32 height if flags[2] is set
44  u32 depth  if flags[2] is set

...

'magic'
 The field 'magic' is the magic number identifying the header, which
 must be the hexadecimal value '0x1BADB002'.

'flags'
 The field 'flags' specifies features that the OS image requests or
 requires of an boot loader.

The problem is here, flags is 0 so it request nothing from the Boot Loader!

'checksum'
 The field 'checksum' is a 32-bit unsigned value which, when added
 to the other magic fields (i.e.  'magic' and 'flags'), must have a
 32-bit unsigned sum of zero.

So the result table returns have not much information you can trust to be there:
   The format of the Multiboot information structure (as defined so far)
follows:

 +---+
 0   | flags |(required)
 +---+
 4   | mem_lower |(present if flags[0] is set)
 8   | mem_upper |(present if flags[0] is set)
 +---+
 12  | boot_device   |(present if flags[1] is set)
 +---+
 16  | cmdline   |(present if flags[2] is set)
 +---+
 20  | mods_count|(present if flags[3] is set)
 24  | mods_addr |(present if flags[3] is set)
 +---+
 28 - 40 | syms  |(present if flags[4] or
 |   |flags[5] is set)
 +---+
 44  | mmap_length   |(present if flags[6] is set)
 48  | mmap_addr |(present if flags[6] is set)
 +---+
 52  | drives_length |(present if flags[7] is set)
 56  | drives_addr   |(present if flags[7] is set)
 +---+
 60  | config_table  |(present if flags[8] is set)
 +---+
 64  | boot_loader_name  |(present if flags[9] is set)
 +---+
 68  | apm_table |(present if flags[10] is set)
 +---+
 72  | vbe_control_info  |(present if flags[11] is set)
 76  | vbe_mode_info |
 80  | vbe_mode  |
 82  | vbe_interface_seg |
 84  | vbe_interface_off |
 86  | vbe_interface_len |
 +---+
 88  | framebuffer_addr  |(present if flags[12] is set)
 96  | framebuffer_pitch |
 100 | framebuffer_width |
 104 | framebuffer_height|
 108 | framebuffer_bpp   |
 109 | framebuffer_type  |
 110-115 | color_info|

Or is it some code that change the flags and checksum somewhere?

I guess flags[6] would be usefull to get memory map:
   If bit 6 in the 'flags' word is set, then the 'mmap_*' fields are
valid, and indicate the address and length of a buffer containing a
memory map of the machine provided by the BIOS.  'mmap_addr' is the
address, and 'mmap_length' is the total size of the buffer.  The buffer
consists of one or more of the following size/structure pairs ('size' is
really used for skipping to the next pair):

 +---+
 -4  | size  |
 +---+
 0   | base_addr |
 8   | length|
 16  | type  |
 +---+

   where 'size' is the size of the associated structure in bytes, which
can be greater than the minimum of 20 bytes.  'base_addr' is the
starting address.  'length' is the size of the memory region in bytes.
'type' is the variety of address range represented, where a value of 1
indicates available RAM, value of 3 indicates usable memory holding ACPI
information, value of 4 indicates reserved memory which needs to be
preserved on hibernation, value of 5 indicates a memory which is
occupied by defective RAM modules and all 

Re: Genode 16.08 nova.iso rebooting on real Core 2 Duo after relocating modules

[Paul Dufresne]

But I seems to have problems on first file compiled when using gcc v6:

In file included from ../src/acpi.cpp:28:0:
../include/acpi_rsdt.hpp:45:26: error: flexible array member in union
 uint32  rsdt[];
  ^
../include/acpi_rsdt.hpp:46:26: error: flexible array member in union
 uint64  xsdt[];

This was freshly downloaded zip file from HEAD (
https://github.com/udosteinberg/NOVA ).

Reading "I.e., flexible array members may be defined only in
structures, not in unions." In C (don't know about C++).
They seems to suggest it should be replaced by zero-sized array (was
not aware of that before).

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html

--
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Genode 16.08 nova.iso rebooting on real Core 2 Duo after relocating modules

[Paul Dufresne]

2016-09-21 8:20 GMT-04:00 Christian Helmuth :
>> Need 05df2000 bytes to relocate modules.
>> Relocating to 7980d000:
>> Copying 483168 bytes...
> [...]
>> Copying 114820 bytes...
>
> If my calculations from this output are correct the boot modules cover
> RAM from 0x7980d000 to 0x7f5e9000. Maybe there's a collision in this
> region?
>
>> paul@arcturus:~$ cat /proc/meminfo
>> MemTotal:2041768 kB
>
> Could you please compare the region above against
>
>   cat /proc/iomem'
>
> and check if it fits completely into "System RAM"?
Ehhh... At first I thought there was a problem... but i think it goes
just before ACPI Non-volatile Storage
0010-7f5ffbff : System RAM
  0100-015cb5d4 : Kernel code
  015cb5d5-01b10aff : Kernel data
  01c67000-01d34fff : Kernel bss
7f5ffc00-7f601bff : ACPI Non-volatile Storage
7f601c00-7f603bff : RAM buffer
7f603c00-7fff : reserved
  7f80-7ff7 : Graphics Stolen Memory

It sure looks like a Nova bug (had time to load modules, but not to
show Nova welcome message).
In src/init I see:
void init (mword mbi)
{
// Setup 0-page and 1-page
memset (reinterpret_cast(_0), 0, PAGE_SIZE);
memset (reinterpret_cast(_1), ~0u, PAGE_SIZE);
for (void (**func)() = _G; func != _E; (*func++)()) ;
Hip::build (mbi);
for (void (**func)() = _C; func != _G; (*func++)()) ;
// Now we're ready to talk to the world
Console::print ("\fNOVA Microhypervisor v%d-%07lx (%s): %s %s [%s]\n",
CFG_VER, reinterpret_cast(_VER), ARCH, __DATE__, __TIME__,
COMPILER_STRING);
Idt::build();
Gsi::setup();
Acpi::setup();
Console_vga::con.setup();
Keyb::init();
}

I believe Hip::(build(mbr) reads the module, and I suppose do the
relocations shown.

I am thinking about adding some Console::print inside the loop:
for (void (**func)() = _C; func != _G; (*func++)()) ;
which I barely understand as calling each functions in an array of
Constructors (CTORS_C).

Wish I would knew where CTORS_C is defined, but I guess I need not to know.
I am not so good with coding... so it might be just to the limit of my
abilities to do and test that.

--
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Checkpoint/restore of capabilities

[Denis Huber]

Hello again,

I have two small problems where I need some guidance from you :)

1. I am trying to understand the mechanism of l4_task_map [1]. Are the 
following thoughts correct?

* The destination and source task cap (first 2 args of l4_task_map) can 
be retrieved through Pd_session::native_pd() and Foc_native_pd::task_cap().
* Send flexpage (arg #3) describes a memory area which contains the 
selector number (= address) of the source task's capability.
* The send base (arg #4) is an integer which contains the address of the 
capability of the the destination task and also an operation code number 
for e.g. mapping or granting the capability.

[1] 
https://l4re.org/doc/group__l4__task__api.html#ga0a883fb598c3320922f0560263da35e6

To iterate through all possible capabilities I need to know where the 
capability space starts (first valid selector number) and where it ends. 
Where can I find these information? I.e. which source files are relevant?

2. I also wanted to look up the mechanism of Noux where it 
re-initializes the parent cap, the noux session cap, and the caps of a 
child's environment after a fork. But I cannot find the corresponding files.


Kind regards,
Denis

On 10.09.2016 11:52, Denis Huber wrote:
> Hello Norman,
>
> thank you for your great answer. I will follow your advise and
> virtualize all necessary services that a target component uses.
>
>
> Kind regards,
> Denis
>
> On 09.09.2016 10:58, Norman Feske wrote:
>> Hi Denis,
>>
>>> The child component shall be migrated from one ECU to another. The
>>> Genode system on the other ECU may have the Rpc_objects, which the child
>>> needs (e.g. shared dataspaces), but their object identities are
>>> different (e.g. other addresses in memory) or the Rpc_objects do not
>>> exist (e.g. a session object between the child and a service).
>>
>> so the problem goes much deeper than merely requesting and populating
>> the child's capability space. You need the replicate the entire child's
>> execution environment at the destination ECU. That means for each
>> capability in possession of the child, your runtime needs to know the
>> exact meaning. E.g., if the child has a session capability to a session
>> created with certain session arguments, the same kind of session must be
>> re-created at the destination ECU. Of course, the same holds for all
>> dataspaces, threads, and other RPC objects that the child can reference
>> via the capabilities present in its capability space.
>>
>> The logical consequence is that the runtime must virtualize all services
>> used by the child. E.g. if the child creates a LOG session, the runtime
>> would create a session to a LOG service in the child's name but hand out
>> a capability locally implemented LOG-session wrapper - similar to what
>> you have already done for the RAM service. So when migrating the child,
>> you now exactly what the various capabilities in the child's capability
>> space mean and can transfer the underlying state to the destination ECU.
>>
>> In principle, this is how Noux solves the fork problem. But in the case
>> of Noux, I deliberately avoid populating the child's capability space
>> with Genode capabilities in order to alleviate the need to virtualize
>> many Genode services. Instead, I let the child use the Noux session as
>> its only interface to the outside world. At the Noux-session level, the
>> child does not talk about Genode capabilities but about file
>> descriptors, for which Noux knows the meaning. Of course there exist a
>> few capabilities in the child's capability space, in particular the
>> parent cap, the Noux-session cap, and the caps of the child's
>> environment. But these few capabilities are manually re-initialized by
>> the freshly created process after the fork.
>>
>> In your case, you want to replicate the child's capability space in a
>> way that is transparent to the child. Like Noux, you need the have a
>> complete model of the child's execution environment in your runtime.
>> Unlike Noux, however, you want to let the child interact with various
>> Genode services. Consequently, your model needs to capture the those
>> services.
>>
>>> During a restore, I will have to relink the Native_capability to the
>>> available Rpc_object or simply recreate the Rpc_object. In both cases I
>>> have to know the types of the Native_capabilities, when I snapshot them
>>> from the Cap Space of the child. Is there a way to find out the type of
>>> a Native_capability through an API function?
>>
>> As discussed above, the type alone does not suffice. Your runtime needs
>> to know the actual semantics behind each capability, e.g., not just the
>> knowledge that a certain capability is a RAM-session capability but also
>> the information how much quota the RAM session has and which dataspaces
>> belong to it. Or as another example, you don't just need to know that a
>> capability is a file-system session but also the session arguments that
>> were used when the session was 

Re: Genode 16.08 nova.iso rebooting on real Core 2 Duo after relocating modules

[Christian Helmuth]

Hello Paul,

On Tue, Sep 20, 2016 at 08:54:22PM -0400, Paul Dufresne wrote:
> I thought rebooting computer as soon has coming to boot line was for
> old low memories computer
> only, but I get it with nova.iso burnt on a CD on my Core 2 Duo, 2 GB
> (well 3 GB, but 2 Gb
> memory stick recognized as only 1 Gb + one other 1 Gb).
> 
> Capture log with null-modem RS232:
> 
> Bender: Hello World.
> Need 05df2000 bytes to relocate modules.
> Relocating to 7980d000:
> Copying 483168 bytes...
[...]
> Copying 114820 bytes...

If my calculations from this output are correct the boot modules cover
RAM from 0x7980d000 to 0x7f5e9000. Maybe there's a collision in this
region?

> paul@arcturus:~$ cat /proc/meminfo
> MemTotal:2041768 kB

Could you please compare the region above against

  cat /proc/iomem'

and check if it fits completely into "System RAM"?

Greets
-- 
Christian Helmuth
Genode Labs

https://www.genode-labs.com/ · https://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

--
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main