[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 17/03/15 14:29, Wei Liu wrote:
I've now successfully built QEMU upstream with rump kernel. However to
make it fully functional as a stubdom, there are some missing pieces to
be added in.

1. The ability to access QMP socket (a unix socket) from Dom0. That
    will be used to issue command to QEMU.
2. The ability to access files in Dom0. That will be used to write to /
    read from QEMU state file.

There's a way to map file access to rump kernel hypercalls with a facility called etfs (extra-terrestrial file system). In fact, the current implementation for accessing the Xen block device from the rump kernel is done using etfs (... historical reasons, I'd have to go back 5+ years to explain why it doesn't attach as a regular block device).

etfs isn't a file system, e.g. it doesn't allow listing files or removing them, but it does give you complete control of what happens when data is read or written for /some/path. But based on the other posts, sounds like it might be enough for what you need.


3. The building process requires mini-os headers. That will be used
    to build libxc (the controlling library).

That's not really a problem, though I do want to limit the amount of interface we claim to support with rump kernels. For example, ISTR you mentioned on irc you'd like to use minios wait.h. It would be better to use pthread synchronization instead of minios synchronization. That way, if we do have a need to change the underlying threading in the future, you won't run into trouble.

So, we should just determine what is actually needed and expose those bits by default.

One of my lessons learned from the existing stubdom stuffs is that I
should work with upstream and produce maintainable code. So before I do
anything for real I'd better consult the community. My gut feeling is
that the first two requirements are not really Xen specific. Let me know
what you guys plan and think.

Yes, please.  If there's something silly going on, it's most likely due to:

1) we didn't get that far in our experiments and weren't aware of it
2) we were aware, but some bits were even sillier, taking priority

Either way, a real need is a definite reason to expedite fixing.

  - antti

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.