Re: Upstream QEMU based stubdom and rump kernel

[Martin Lucina <martin@lucina.net>]

anil@recoil.org said:
> > Point 2. will further require implementing support in the Rump Kernel,
> > either for a shim which would proxy AF_UNIX / AF_INET transparently using
> > vchan, or possibly later implementing a separate socket family (AF_VCHAN /
> > AF_HYPER?). Once that is done you should be able to just drop it in to
> > QEMU on Rump.
> 
> I'm a little wary of point 2) asking for filesystem access to dom0.  What
> exactly is the qemu state API?  Does it need arbitrary file access, or is
> there a slightly higher level set of operations that could be marshalled
> along the socket?  In fact, why doesn't qemu privilege separate and use
> a QMP socket for its host filesystem operations as well?

Email thread context confusion here. I meant point 2 that I wrote
(connecting up Rump<->Mirage domUs where the Rump application is unmodified
and listens on what it believes is AF_INET/AF_UNIX).

Regarding the qemu state API, as I understood from others replies to the
full thread
(http://www.freelists.org/post/rumpkernel-users/Upstream-QEMU-based-stubdom-and-rump-kernel)
the state API does not require filesystem access and can be made to work
over a socket.

Martin