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

Eliot Miranda eliot.miranda at gmail.com
Wed Dec 16 20:13:04 UTC 2015


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.

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?).


_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151216/db478c39/attachment.htm


More information about the Vm-dev mailing list