Hi,
I tried booting a 64bit hello world program on L4/Fiasco but that fails with a region overlap:
============================================= xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019dd88 TOTAL: 0000000000000000->000000007f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003fb 1GB PAGES: 0x0000000000000000 Daemon running with PID 9320 net0: 00:16:3e:72:79:e5 using rtl8139 on PCI00:04.0 (open) [Link:up, TX:0 TXE:0 RX:0 RXE:0] DHCP (net0 00:16:3e:72:79:e5)... ok net0: 192.168.178.200/255.255.255.0 gw 192.168.178.54 Booting from PXE menu boot PXEBS (net0 type 128).... ok Next server: 192.168.178.54 Filename: pxeboot.0 tftp://192.168.178.54/pxeboot.0... ok
L4 Bootstrapper Build: #7 Sun Jun 9 16:51:46 CEST 2013, x86-64, 4.6.3 RAM: 0000000000000000 - 000000000009a7ff: 618kB RAM: 0000000000100000 - 000000007f7b9fff: 2087656kB Total RAM: 2039MB New region for list regions: [ 20d000, 4c62c9] { 2b92ca} Root Module overlaps with: [ 2d0080, 2e45c7] { 14548} Boot bootstrap Regions of list 'regions' [ 0, fff] { 1000} Arch BIOS [ e0000, fffff] { 20000} Arch BIOS [ 106000, 1a646f] { a0470} Root Module [ 1a7000, 20c9bd] { 659be} Root Module [ 2d0080, 2e45c7] { 14548} Boot bootstrap [ 1013000, 10a8fff] { 96000} Boot bootstrap-ptab64 [ fc000000, ffffffff] { 4000000} Arch BIOS region overlap
Key press reboots... =============================================
Everything works for 32bit. I took a look at bootstrap/server/src/startup.cc. I verified that modaddr is correctly passed to boostrap in both cases (32 and 64bit; it is 0x2000000 everytime). It appears that the failure happens in the call to add_boot_modules_region():
/* we're just a GRUB-booted kernel! */ add_boot_modules_region(mbi);
if (_mod_addr) move_modules(mbi, _mod_addr);
I do not fully understand all this code but to me this looks like a logic error: first the move should happen to honor "-modaddr" and only then the overlap check should be done.
Here is the output for 32bit: ============================================= L4 Bootstrapper Build: #3 Sun Jun 9 16:55:38 CEST 2013, x86-32, 4.6.3 RAM: 0000000000000000 - 000000000009a7ff: 618kB RAM: 0000000000100000 - 000000007f7b9fff: 2087656kB Total RAM: 2039MB Moving up to 7 modules behind 2000000 moving module 00 { 139000-1ba783 } -> { 2829000-28aa783 } [530308] moving module 01 { 1bb000-21015e } -> { 28ab000-290015e } [348511] moving module 02 { 2e5000-51f51c } -> { 2901000-2b3b51c } [2336029] moving module 03 { 520000-762e3b } -> { 2000000-2242e3b } [2371132] moving module 04 { 763000-8880c6 } -> { 2243000-23680c6 } [1200327] moving module 05 { 211000-211080 } -> { 2369000-2369080 } [129] moving module 06 { 889000-9616a6 } -> { 236a000-24426a6 } [886439] Scanning /fiasco -serial -serial_esc -comspeed 115200 -comport 1 -nokdb Scanning /sigma0 Scanning /moe rom/hello.lua Bootloader MMAP: [ 0, 9a800) RAM (1) [ e0000, 100000) reserved (2) [ 100000, 7f7ba000) RAM (1) [ fc000000, 100000000) reserved (2) Relocated mbi to [0x2e0000-0x2e043f] Loading /fiasco Loading /sigma0 Loading /moe find kernel info page... found kernel info page at 0x400000 ... =============================================
Since the module addresses are also different between the two version this might also be an issue with the linker scripts (and thus just luck that the 32bit version boots), I would guess. I am using a Xen VM for testing. Any help would be appreciated.
Thanks, Daniel
On Sun Jun 09, 2013 at 17:06:50 +0200, Daniel Müller wrote:
I tried booting a 64bit hello world program on L4/Fiasco but that fails with a region overlap:
============================================= xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019dd88 TOTAL: 0000000000000000->000000007f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003fb 1GB PAGES: 0x0000000000000000 Daemon running with PID 9320 net0: 00:16:3e:72:79:e5 using rtl8139 on PCI00:04.0 (open) [Link:up, TX:0 TXE:0 RX:0 RXE:0] DHCP (net0 00:16:3e:72:79:e5)... ok net0: 192.168.178.200/255.255.255.0 gw 192.168.178.54 Booting from PXE menu boot PXEBS (net0 type 128).... ok Next server: 192.168.178.54 Filename: pxeboot.0 tftp://192.168.178.54/pxeboot.0... ok
So the environment is a Xen HVM and pxeboot.0 being the multiboot loader?
Adam
Hi,
On 06/10/13 00:57, Adam Lackorzynski wrote:
On Sun Jun 09, 2013 at 17:06:50 +0200, Daniel Müller wrote:
I tried booting a 64bit hello world program on L4/Fiasco but that fails with a region overlap:
============================================= xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019dd88 TOTAL: 0000000000000000->000000007f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003fb 1GB PAGES: 0x0000000000000000 Daemon running with PID 9320 net0: 00:16:3e:72:79:e5 using rtl8139 on PCI00:04.0 (open) [Link:up, TX:0 TXE:0 RX:0 RXE:0] DHCP (net0 00:16:3e:72:79:e5)... ok net0: 192.168.178.200/255.255.255.0 gw 192.168.178.54 Booting from PXE menu boot PXEBS (net0 type 128).... ok Next server: 192.168.178.54 Filename: pxeboot.0 tftp://192.168.178.54/pxeboot.0... ok
So the environment is a Xen HVM and pxeboot.0 being the multiboot loader?
Yes, I use grub2's grub-mkimage to create pxeboot.0.
Daniel
On 06/09/2013 05:06 PM, Daniel Müller wrote:
Hi,
I tried booting a 64bit hello world program on L4/Fiasco but that fails with a region overlap:
============================================= xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019dd88 TOTAL: 0000000000000000->000000007f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003fb 1GB PAGES: 0x0000000000000000 Daemon running with PID 9320 net0: 00:16:3e:72:79:e5 using rtl8139 on PCI00:04.0 (open) [Link:up, TX:0 TXE:0 RX:0 RXE:0] DHCP (net0 00:16:3e:72:79:e5)... ok net0: 192.168.178.200/255.255.255.0 gw 192.168.178.54 Booting from PXE menu boot PXEBS (net0 type 128).... ok Next server: 192.168.178.54 Filename: pxeboot.0 tftp://192.168.178.54/pxeboot.0... ok
L4 Bootstrapper Build: #7 Sun Jun 9 16:51:46 CEST 2013, x86-64, 4.6.3 RAM: 0000000000000000 - 000000000009a7ff: 618kB RAM: 0000000000100000 - 000000007f7b9fff: 2087656kB Total RAM: 2039MB New region for list regions: [ 20d000, 4c62c9] { 2b92ca} Root Module overlaps with: [ 2d0080, 2e45c7] { 14548} Boot bootstrap
This is problem is caused by the way bootstrap works on 64-bit systems. If there is a module at 0x2d0000, bootstrap will overwrite that with its own 64-bit code and then figure out later that things are b0rken.
I don't know a good workaround for this, except having a bootloader that moves modules out of the way. You might try bender in my firewire toolchain: https://github.com/TUD-OS/morbo
It is a multiboot 'kernel' whose purpose it is to find PCI serial controllers, but it will also move any remaining modules to high memory before executing them, so bootstrap will not destroy them.
Julian
Hi,
On 06/10/13 18:09, Julian Stecklina wrote:
This is problem is caused by the way bootstrap works on 64-bit systems. If there is a module at 0x2d0000, bootstrap will overwrite that with its own 64-bit code and then figure out later that things are b0rken.
Thanks for the explanation. Does this mean this is a general problem for 64 bit? And it is on the side of bootstrap? That sounds to me like the fix should be on that side as well. Why not change the 0x2d0000 address? Anyway, so could I just insert a dummy module and set the overlap_allowed flag (or whatever the name is) in the source code?
I don't know a good workaround for this, except having a bootloader that moves modules out of the way. You might try bender in my firewire toolchain: https://github.com/TUD-OS/morbo
I might give it a try but I'd rather prefer staying with a more mainstream one.
Thanks, Daniel
On 06/10/2013 11:28 PM, Daniel Müller wrote:
Hi,
On 06/10/13 18:09, Julian Stecklina wrote:
This is problem is caused by the way bootstrap works on 64-bit systems. If there is a module at 0x2d0000, bootstrap will overwrite that with its own 64-bit code and then figure out later that things are b0rken.
Thanks for the explanation. Does this mean this is a general problem for 64 bit? And it is on the side of bootstrap? That sounds to me like the
It is a bootstrap implementation problem. Could be fixed. You may volunteer. ;)
fix should be on that side as well. Why not change the 0x2d0000 address? Anyway, so could I just insert a dummy module and set the overlap_allowed flag (or whatever the name is) in the source code?
Adam's grub ( https://os.inf.tu-dresden.de/~adam/grub/ ) can load modules at higher addresses via the modaddr command, which probably also solves your problem.
I don't know a good workaround for this, except having a bootloader that moves modules out of the way. You might try bender in my firewire toolchain: https://github.com/TUD-OS/morbo
I might give it a try but I'd rather prefer staying with a more mainstream one.
It is not a bootloader per se. It is a multiboot-compliant chainloader that (among other things) relocates modules to a safe place. So usage in a e.g. grub would be:
kernel /morbo module /bootstrap module /fiasco ...
Julian
Hi,
On 06/11/13 15:59, Julian Stecklina wrote:
On 06/10/2013 11:28 PM, Daniel Müller wrote:
On 06/10/13 18:09, Julian Stecklina wrote:
This is problem is caused by the way bootstrap works on 64-bit systems. If there is a module at 0x2d0000, bootstrap will overwrite that with its own 64-bit code and then figure out later that things are b0rken.
Thanks for the explanation. Does this mean this is a general problem for 64 bit? And it is on the side of bootstrap? That sounds to me like the
It is a bootstrap implementation problem. Could be fixed. You may volunteer. ;)
Alright, got it working now (see attached patch). If this is to be integrated into svn I can do some cleanups and check for errors that might have crept in -- just let me know.
Daniel
l4-hackers@os.inf.tu-dresden.de