Re: Upstream QEMU based stubdom and rump kernel

[Antti Kantee <pooka@iki.fi>]

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.