[Vm-dev] Re: Cog Rump Xen unikernel (spur mmap)

[Ben Coman]

On Thu, Dec 17, 2015 at 4:13 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> Hi Ben,
>
> On Wed, Dec 16, 2015 at 10:46 AM, Ben Coman <btc at openinworld.com> wrote:
>>
>>
>> On Thu, Dec 17, 2015 at 1:43 AM, Ben Coman <btc at openinworld.com> wrote:
>> > I'm having a go at getting this working with the Spur svn sources per...
>> > http://www.mirandabanda.org/cogblog/compiling-the-vm/
>>
>> @Eliot,
>> I am currently stuck on Spur's requirement for mmap.
>> Could you describe this requirement and any ideas on path to proceed
>> to check compatibilty with these...
>
>
> The key here is that Spur's heap is segmented.  In Unix or Windows we use mmap or its equivalent to obtain memory for additional segments when the heap grows.  In a Xen context as I understand it, there is no virtual memory, only segments of memory that Xen will give to an application above it.  hence the problem is to mate Xen memory segments to Spur, in which case you will discard the use of mmap.  Xen is a new platform; see below.
>
> There are constraints here.  The VM assumes the following memory order:
>
> Low addresses:
>     machine code zone
>     new space
>     first heap segment
>
> High addresses
>     subsequent heap segments
>
> So in using memory from Xen you'll want to ask for some amount of memory in the form of segments, and initialise the VM so that the segments are used in line with these constraints.  Does that make sense?
>
> Now there's an assumption that the machine code zone, new space and the first heap segment are contiguous, but that's not fundamental, merely historical convenience.  As long as the regions are in the order machine code zone < new space < first heap segment things all work.  So you may have to rewrite some of the image loading code if you can't obtain a segment large enough to accomodate all of the machine code zone, new space and the first heap segment.


Makes sense.  What is the expected size of that initial segment?


>> https://github.com/rumpkernel/wiki/wiki/Info:-FAQ
>> says "For simplicity reasons, the Rumprun unikernel does not support
>> virtual memory -- unnecessary in a unikernel -- nor does it support
>> signals the traditional way. That means that programs which absolutely
>> depend on things like fork(),execve(), mmap() and sigaction() may not
>> work correctly. In some cases we provide a small amount of cheap
>> emulation for common cases (e.g. mmap(MAP_ANON))"
>>
>> http://rumpkernel.org/misc/usenix-login-2014/login_1410_03_kantee.pdf
>> says "The more or less only negative effect caused by the lack of
>> virtual memory support is that the mmap() system call cannot be fully
>> handled by a rump kernel. A number of workarounds are possible for
>> applications that absolutely need to use mmap(). For example, the
>> bozohttpd Web server uses mmap() to read the files it serves, so when
>> running bozohttpd on top of a rump kernel, we simply read the mmap’d
>> window into memory at the time the mapping is made instead of
>> gradually faulting pages in. A perfect emulation of mmap() is hard to
>> achieve, but one that works for most practical purposes is easy to
>> achieve"
>>
>> cheers -ben
>>
>> P.S. Here is the compilation error...
>>
>> platforms/unix/vm/sqUnixSpurMemory.c:72:3: error: #error "Spur requires mmap"
>>  # error "Spur requires mmap"
>>    ^
>> platforms/unix/vm/sqUnixSpurMemory.c: In function ‘sqAllocateMemory’:
>> platforms/unix/vm/sqUnixSpurMemory.c:108:47: warning: passing argument
>> 3 of ‘sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto’ from
>> incompatible pointer type
>>      (roundUpToPage(desiredHeapSize), address, &allocBytes);
>>                                                ^
>> In file included from platforms/unix/vm/sqUnixSpurMemory.c:33:0:
>> platforms/Cross/vm/sq.h:88:14: note: expected ‘sqInt *’ but argument
>> is of type ‘long unsigned int *’
>>  extern void *sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto(sqInt
>> sz, void *minAddr, sqInt *asp);
>>               ^
>> Makefile:276: recipe for target 'sqUnixSpurMemory.o' failed
>> make[1]: *** [sqUnixSpurMemory.o] Error 1
>> Makefile:407: recipe for target 'vm/vm.a' failed
>> make: *** [vm/vm.a] Error 2
>
>
> If I were you I would create a new platform, xen, under platforms, being a sibling of platforms/unix.  I would implement the relevant support for Xen there-in.  I'd also decide whether what I was producing was headful or headless (the latter I presume?).


I think the platform is more "rumprun" which is the first layer Spur
deals with, then there are a few options below rumprun that might be
better to capture as a build...
  .../platforms/rumprun
  ../build.xenrumprun.32x86
  ../build.xenrumprun.32ARM
  ../build.baremetalrumprun.32x86
  ../build.baremetalrumprun.32ARM
  ../build.KVMrumprun.32x86
  ../build.KVMrumprun.32ARM

or maybe
  ../build.rumprun.Xen32x86
  ../build.rumprun.Xen32ARM
  ../build.rumprun.baremetal32x86
  ../build.rumprun.baremetal32ARM
  ../build.rumprun.KVM32x86
  ../build.rumprun.KVM32ARM

cheers -ben