Vancouver fails to allocate guest memory

[parthy]

I get

Not enough space (0x3789000) left for VMM, VM image to large

when starting my modified Vancouver. This problem used to be possible to handle by fiddling with the _initial_junk size or by commenting out exception handling sections in Vancouver. But with the most recent master branch, I cannot get it to work anymore. Is there any quickfix I can try?

[alex-ab]

Check out only until 5e66b6d of master. I presume I know what went wrong, I will investigate.

[alex-ab]

Running 64bit Seoul/Vancouver results in:

[init -> fb_drv] Found: VESA BIOS version 3.0
[init -> fb_drv] OEM: NVIDIA
[init -> fb_drv] Found: physical frame buffer at 0xd9000000 size: 0x00e00000
[init -> fb_drv] int Framebuffer_drv::map_io_mem(Genode::addr_t, Genode::size_t, bool, void**, Genode::addr_t, Genode::Dataspace_capability*): fb mapped to 1800000
[init -> fb_drv] Framebuffer::Session_component::Session_component(unsigned int, unsigned int, unsigned int, Genode::Dataspace_capability, bool): use buf size 1572864
[init -> fb_drv] using buffered output
[init -> nitpicker] framebuffer is 1024x768@1
[init] child "nitpicker" announces service "Nitpicker"
[init -> nitpicker] create session with args: fb_format=1, label="launchpad", ram_quota=1646592
[init -> nitpicker] Could not open file "config"
[init -> nitpicker] Could not obtain config file
[init -> nitpicker] create session with args: fb_width=400, fb_height=1504, fb_format=1, label="launchpad", ram_quota=1211392
[init -> launchpad] --- entering main loop --
[init -> launchpad] starting init with quota 301989888
[init -> launchpad] using unique child name "init"
[init -> launchpad -> init] Could not open file "ld.lib.so"
[init -> launchpad -> init -> vancouver] C++ runtime: Genode::Rm_session::Region_conflict
[init -> launchpad -> init -> vancouver] void* abort(): abort called

I like this bug. Really!

It will not disappear. I hate to cite myself (from commit above):

vmm: try to reserve lower virtual address space
It's not guaranteed to be robust and will break in the future - I told you.

The reason is that on 64bit somebody already attached a region of size 0x8000 to the low virtual address space region. All kind of attempts so far to reserve the region during startup are already to late, the mapping is just there.

[parthy]

I can confirm this, I hit this again too lately. I get it on 32bit as well. The trick you told me (increasing the initial_heap size) helps in the 32bit case, but not for 64bit. So if you want me to test something on my diva machine, just tell me ;) Last year I also noticed that not having a try-catch-block in the main function sometimes helped. So could this be exception-handling related?

[alex-ab]

@parthy: can you please try the commit above ?

[parthy]

There is no region conflict anymore, but I don't get output from Vancouver. I can see the framebuffer session being created, but then nothing happens anymore. So apparently the guest_memory creation fails...

[alex-ab]

Right. On my serial output I get:

device: intel82576vf
[init -> launchpad -> init -> vancouver] configuration error: device model 'intel82576vf' does not exist
[init -> launchpad -> init -> vancouver] C++ runtime: Machine::Config_error
[init -> launchpad -> init -> vancouver] void* abort(): abort called

So, apparently I have to take this model from the VMM configuration since it does not work on 64bit

[alex-ab]

I enabled the intel82576 model for 64bit hosts. Now I get (when using r3_debug):

[init -> launchpad -> init -> vancouver] VMM: Attached 82576VF model at f7ce0000+0x4000, f7cc0000+0x1000
[init -> launchpad -> init -> vancouver] 
[init -> launchpad -> init -> vancouver] --- Booting VM ---
[init -> launchpad -> init -> vancouver] VMM: RESET device state
[init -> launchpad -> init -> vancouver] VMM: MessageLegacy::RESET requested
[init -> launchpad -> init -> vancouver] VMM: INIT done
[init -> launchpad -> init -> vancouver] VMM: reset CPU from 9 mtr_in e0010
[init -> launchpad -> init -> vancouver] VMM: receive() line 273: 'needed_len > r->length' error = 1VMM:  WRITE no idea how to increase the table ebda size from 5120 to 8192VMM: 
[init -> launchpad -> init -> vancouver] VMM: > bool VirtualBiosMultiboot::receive(MessageBios&) rip ffff ilen 0 cr0 10 efl 2
[init -> launchpad -> init -> vancouver] VMM:   module 0 start 11800000+1000 cmdline munich
[init -> launchpad -> init -> vancouver] VMM:   module 1 start 11802000+1c7000 cmdline bzImage-3.1 root=/dev/ram0 earlyprintk=ttyS0 vga=0x314
[init -> launchpad -> init -> vancouver] VMM: Hello, this is the network receiver.
[init -> launchpad -> init -> vancouver] VMM:   module 2 start 119ca000+2bad000 cmdline tc-browser.gz
[ 0] Killed EC:0xffffffff830c3a00 SC:0xffffffff830ec040 V:0x30 CR0:0x11 CR3:0x0 CR4:0x0 (vTLB addressing limit exceeded)

[parthy]

Looks familiar :) See here: TUD-OS/NRE#33

[alex-ab]

Ok. I rebased all our stuff to the the latest commit of the vanilla kernel (using https://github.com/alex-ab/NOVA/tree/staging_genode) and now the 64bit seoul-fancy stuff works for me.

[parthy]

Great, I will give it a spin later today.

[parthy]

Yep, that works.

[alex-ab]

Thank you for testing. Everything is now on genode/staging and r3 kernel branch is updated accordingly.