[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mirage xen shared memory rings

This sounds great (particularly the "hack from userspace using gntdev" bit).  
My latest changes should help this effort, as Bigarray/cstruct will be 
available for your use.

Is there a particular kernel version we should use for the userspace gntdev 
stuff? I fixed a few things that ended up in 3.5 I think, but I'm not sure what 
else has been fixed up since.

Note also that Steven Smith is experimenting with a variable-length multi-page 
netback at the moment, in order to just write packets inline and skip grant 
mappings entirely.  This should be quite easy to integrate with your code, 
along with an implementation of vchan.


On 10 Dec 2012, at 17:44, Dave Scott <Dave.Scott@xxxxxxxxxxxxx> wrote:

> Hi,
> I've recently been hacking on the mirage xen shared memory ring code. This 
> code is the foundation for the virtual devices, in particular
> * disks
> * network interfaces
> * console (critical for debugging)
> * xenstore (critical for attaching other devices)
> I've created a standalone library here:
> https://github.com/djs55/shared-memory-ring
> I've added a set of simple unit tests and fixed a bug where console output 
> was being silently dropped (!) I think this explains the loss of debug 
> messages that Balraj and I saw while investigating the TCP problem. The 
> console and xenstore rings are now also lots faster since they use 
> Bigarray.blit rather than a hand-coded copy-one-byte-at-a-time-while-loop.
> My next steps are:
> 1. to make this library a dependency of the mirage-platform (rather than 
> having the code inline)
> 2. to extract the xen disk and network interface support from mirage-platform 
> and make these into separate libraries too
> 3. to define a shared-memory transport for logging / stats collecting
> (2) should be interesting because the same xen disk and network interface 
> support code should "just work" from userspace as well as kernelspace, if we 
> add ocaml bindings for the xen "gntdev" library which allows userspace access 
> to memory pages "granted" by a VM. It should be possible to:
> a. "opam install gntdev blkback vhd" to install the relevant libraries and 
> then
> b. instantiate the blkback functor with the gntdev interface and the 
> vhd-writing code to make a fully-functional xen virtual disk device from a 
> toplevel... how cool would that be?! (Maybe it's just me...)
> Cheers,
> Dave



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.