Hello! I am trying to implement allocate_at() Libc:: function, which allocate memory region in given (desired) address. To implement I need to extend dataspace (as I understand, this is physical memory) at appropriate address, and later attach it to the local allocator.
I found that memory allocation code from base/include/region_map/region_map.h /** * Shortcut for attaching a dataspace at a predefined local address */ Local_addr attach_at(Dataspace_capability ds, addr_t local_addr, size_t size = 0, off_t offset = 0) { return attach(ds, size, offset, true, local_addr); }
does work for NOVA, but do not work for seL4 kernel for x86_64. This happens when I try to allocate 64k from pre-defined addresses like (try in order) 0xc000000000, 0x1c000000000, 0x2c000000000/etc… I create function int Libc::Mem_alloc_impl::Dataspace_pool::expand_at(size_t size, void * ptr, Range_allocator *alloc)
and inside it, in my call to try { new_ds_cap = _ram->alloc(size);
local_addr = _region_map->attach_at(new_ds_cap, addr_t(ptr), size); }
in seL4 it catch exception catch (Region_map::Region_conflict) {
while same calls in NOVA works ok. Problem happens in second call to attach_at(), new_ds_cap is ok.
Are there significant difference in the memory allocation process (for particular addresses ranges) between NOVA and seL4?
Thanks! Alexander
Hello Alexander,
This happens when I try to allocate 64k from pre-defined addresses like (try in order) 0xc000000000, 0x1c000000000, 0x2c000000000/etc…
...
Are there significant difference in the memory allocation process (for particular addresses ranges) between NOVA and seL4?
On seL4, the virtual address space is limited to 8 GiB [1] on x86_64. On NOVA, the limit is much larger [2].
The memory allocation varies very much between the kernels. On seL4, it is particularly complicated because all virtual-memory structures have to be managed at the user level (Genode's core).
In general, one cannot make assumptions about the virtual address space layout that hold on all the different kernels. Even the location of the stack area may vary.
For this reason, 'attach_at' is not robust when used on the PD's region map. It is useful to manually manage the layout of so-called managed dataspaces (created via the Rm_session interface). Examples of such managed dataspaces are the linker area and the stack area.
[1] https://github.com/genodelabs/genode/blob/master/repos/base-sel4/src/core/pl... [2] https://github.com/genodelabs/genode/blob/master/repos/base-nova/src/core/pl...
Cheers Norman