Re: [Xen-devel] Upstream QEMU based stubdom and rump kernel

[Antti Kantee <pooka@xxxxxx>]

On 18/03/15 19:05, Anil Madhavapeddy wrote:
> > This fits in with a couple of things I hope to make time to work on in the
> > next couple of months:
> >
> > 1. Introspection of Rump Kernel domUs for ops purposes, i.e. get some
> >     basic "ps", "top", "vmstat"-like information about what the domU is
> >     doing from the dom0.
> >
> > 2. Connecting up multiple Rump Kernel domUs and/or Mirage domUs. The
> >     general idea here is that you can have e.g. a Mirage domU running a
> >     HTTP+TLS frontend, communicating with a Rump Kernel domU running PHP +
> >     FastCGI.
> >
> >     The Mirage folks are already doing something similar in their
> >     Jitsu work, using a protocol called Conduit which runs over vchan.
> Yeah, this is currently requiring a couple of things:
>
> - kicking the tires with Vchan and its associated machinery, which has
>    taken some time.  Dave Scott has built a complementary system for
>    the xentropyd which simply sets up a console ring instead of vchan.
>    This has the drawback of being a single fixed page, but far simpler.
>
> - A XenStore protocol for setting up stream connections.  This could
>    indeed quite easily turn into a AF_VCHAN that could be transparently
>    used by rump/Mirage/HaLVM and normal domUs for VM<->VM comms.
This is not an argument for or against; if you want to expose 
AF_WHATEVER to applications running on a rump kernel, you need to sell 
AF_WHATEVER to NetBSD, not to rumpkernel-users.  Well, preferably you 
need to sell it to everyone implementing sockets and running on some 
sort of hypervisor, but of course gotta start from somewhere.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel