Re: [Xen-devel] Rumprun based upstream QEMU stubdom status update

[Eric Shelton <eshelton@xxxxxxxxx>]

Thanks for taking the time to consider my comments and respond.

On Tue, Nov 24, 2015 at 9:44 AM, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:

Another chunk of work is teaching QEMU to not initialised some
component or take a different path when initialising some
components. This is the same as Linux-based stubdom.

When I was working on Linux-based stubdom earlier, it was the point where serious QEMU-related work needed to be done Â(in particular, working out getting the display to work correctly via VNC or otherwise) that I reached the limit of what I could accomplish on my own in a reasonable amount of time. There was simply too much for me to learn about QEMU internals and how they are supposed to interact with Xen. On top of that, getting QMP and save/restore working across domains appears to require some serious effort, and is for the most part outside of what I need QEMU stubdom for.

Â

One lesson learned from QEMU-trad stubdom is that the build system
inevitably turns into a black hole that sucks in effort but yields no
clear return. That's why we would very much prefer doing things "the
right way", i.e. relying on well-established ways to deliver this
feature, and expanding the user base till it is large enough to draw
enough interest for this feature to be self-sustained.

That last bit is where I am interested in bringing this to - having the basic functionality in place, so that others may be encouraged to drive to completion the aspects that they have an interest or stake in. Right now, there is so much that needs to be done, that many would rather not touch any of it.

Â

What is really not clear at the moment is the path to Linux
distributions and BSDs. Xen project doesn't distribute binaries. Also
, to build an image requires specialised toolchain and build system
that distros are not interested in taking in. Building for *BSD is a
no-go at the moment for Linux-based stubdom and QEMU-trad stubdom.

I agree that for the time being, *BSD would be off the table for Linux-based stubdom - it would take a lot of bootstrapping to get an environment up and running under *BSD to build the Linux-based stubdom on *BSD.

It could be sensible to modify the no-binaries position if the notion of a reproducible build could be implemented. This could allow distribution of a binary image for Linux-based stubdom (which would not be all that big) for use by *BSD and others, yet demonstrate that the binary image does correspond to the underlying source. However, that is several step down the road from just getting it to work on Linux.

Â

I discussed with Stefano and Anthony to reassess Linux-based stubdom,
with all the issues mentioned above, if we narrow down the scope of
the project -- ignore BSD support for now, integrate build with
Raisin, no distros integration -- it can actually be done within a
finite time frame.

Here are some issues with the existing patch series:

1. It's using Dracut build image, which is Redhat-centric.

That issue was raised before, but I'm not sure how much it really is. FWIW, I was using my updated version of Anthony's work on a Gentoo system, and encountered no issues. Is there a Linux distribution that we know dracut does not work on? It would be helpful to know. Although I have not really dug into dracut, it seemed to be effective for our purposes (collecting the libraries that need to be included in the Linux image for QEMU), and I'd rather not recreate dracut or part of dracut if we don't need to.

Â

2. Some patches are not yet complete and not suitable to upstream.

What kinds of things are being done by these patches? You mentioned component initialization; however, I did not encounter any problems relating to that when getting QEMU upstream stubdom up to the point of running SSH on a standard Linux distribution, etc. Having to disable such things makes sense as an issue under rumprun, given the likely difficulties in getting certain libraries to run under rumprun, but I would expect it to be less of an issue when QEMU gets run in its native Linux environment.

Â

And these are the steps that need to be done:

1. Build with Raisin
 1.1 Build Linux kernel with a customised config.
 1.2 Build QEMU from a customised branch.
 1.3 Extract QEMU libraries dependency with generic tool.
 1.4 Generate a disk image with generic tool.
2. Toolstack plumbing and make work other components.
3. Teach OSStest to constantly test it.

Would you be up for working on Raisin integration? That is, up to the
point of producing an image. We can discuss certain actions in
detailed and will help you with the issues you encounter along the
way. We appreciate help from the community as we're already quite
stretched with other projects.

I believe that is something I can work on, and likely won't be all that bad given where things already are. However, I know essentially nothing about Raisin. What is a good way to get up to speed?

One issue that was raised previously is where would the Raison/Xen build process download the Linux kernel source from? Âkernel.org? A cloned branch on xenbits? I don't see any need to have a customized branch - the stock Linux kernel should work just fine, and we just need to supply a .config to get the appropriate features built into the kernel.

Is there anyone that can be tapped to address at least some of the initial QEMU issues? To get this up to a minimal "tech preview" status, we need to get the display, keyboard input, and mouse input working - having Windows working at a basic level under QEMU upstream stubdom seems like a good target. As I mentioned above, I don't have, and don't have the time to acquire, the necessary QEMU skills to make that work. If there is someone who can look at it, a basic non-Raisin build approach can be provided that should allow a developer to build and debug QEMU upstream stubdom.

Wei.

> All the best,
> Eric
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel