Hi Ben,

On Wed, Dec 16, 2015 at 10:46 AM, Ben Coman <btc@openinworld.com> wrote:

On Thu, Dec 17, 2015 at 1:43 AM, Ben Coman <btc@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