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

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 18 Mar 2015, at 20:23, Antti Kantee <pooka@xxxxxx> wrote:
> 
> 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.

Given that most of the uses of this will be in userspace code, just
faking out AF_UNIX in Rump does seem a lot easier.  It doesn't matter
to MirageOS either way -- we just need a well-defined XenStore/ring
protocol to obey to do connection setup on the other side.

-anil


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel