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.
See:
http://man.netbsd.org/cgi-bin/man-cgi?rump_etfs++NetBSD-current
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
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel