Re: Upstream QEMU based stubdom and rump kernel

[Ian Campbell <ian.campbell@citrix.com>]

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.