From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antti Kantee Subject: Re: Upstream QEMU based stubdom and rump kernel Date: Wed, 18 Mar 2015 20:23:17 +0000 Message-ID: <5509DEB5.8060906@iki.fi> References: <20150317142907.GD27314@zion.uk.xensource.com> <20150318112014.GC17247@nodbug.moloch.sk> <4558D0C0-8058-4052-994C-6138406CEB35@recoil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4558D0C0-8058-4052-994C-6138406CEB35@recoil.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: anil@recoil.org, Martin Lucina Cc: David Scott , Wei Liu , Ian Campbell , Stefano Stabellini , Ian Jackson , Richard Mortier , xen-devel@lists.xen.org, rumpkernel-users@freelists.org, Thomas Gazagnaire , Anthony PERARD List-Id: xen-devel@lists.xenproject.org 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.