[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Rumprun based upstream QEMU stubdom status update
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 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 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 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, 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: 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.
_______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |