From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Upstream QEMU based stubdom and rump kernel Date: Tue, 17 Mar 2015 15:07:24 +0000 Message-ID: <1426604844.18247.266.camel@citrix.com> References: <20150317142907.GD27314@zion.uk.xensource.com> <1426604049.18247.260.camel@citrix.com> <20150317145756.GE27314@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150317145756.GE27314@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: Anthony PERARD , rumpkernel-users@freelists.org, Ian Jackson , Stefano Stabellini , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Tue, 2015-03-17 at 14:57 +0000, Wei Liu wrote: > On Tue, Mar 17, 2015 at 02:54:09PM +0000, Ian Campbell wrote: > > On Tue, 2015-03-17 at 14:29 +0000, Wei Liu wrote: > > > 2. The ability to access files in Dom0. That will be used to write to / > > > read from QEMU state file. > > > > This requirement is not as broad as you make it sound. > > > > Yes. You're right. > > > All which is really required is the ability to slurp in or write out a > > blob of bytes to a service running in a control domain, not actual > > This is more accurate. It's probably also worth also mentioning that it is a streaming read or write, no need to support seek or such things. > > ability to read/write files in dom0 (which would need careful security > > consideration!). > > > > For the old qemu-traditional stubdom for example this is implemented as > > a pair of console devices (one r/o for restore + one w/o for save) which > > are setup by the toolstack at start of day and pre-plumbed into two > > temporary files. > > > > Unfortunately I don't think that hack in mini-os is upstreamable in rump > kernel. The mini-os implementation is hacky, it is ultimately just a way of implementing open("/dev/hvc1", "r") without actually having to have all of that sort of thing really. But the concept of "open a r/o device and read from it" (or vice versa) doesn't seem to be too bad to me and I expected rumpkernels to have some sort of concept like this somewhere. Ian.