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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Nov 24, 2015 at 11:16:47PM -0500, Eric Shelton wrote:
[...]
> 
> > 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.
> 

I can't recollect previous objections. If we know dracut is packaged in
most major distributions then I don't have objection to it.

Currently in Anthony's patch set, dracut is downloaded and built. That's
not ideal. To integrate with Raisin, the only viable way is to install
packaged Dracut -- building the tool to build image itself is not
acceptable to me.

> 
> > 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.
> 

The current patch set disables some components due to Anthony didn't
have time to implement them. Those patches need to be reworked.

> 
> > 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?
> 

There is a wiki page for Raisin.

http://wiki.xenproject.org/wiki/Raisin

I guess the most effective way is to just give it a try and post
questions to xen-devel.

> 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.
> 

Right. These are the details.

I was thinking we pick one of our tested branch in xenbits. We also need
a minimal .config for the kernel. I think you can extract the one in
Anthony's patch series.

Another way is, as you said, to just use the stock kernel. Then we need
to make sure it is xen-capable.

Details can be discussed in another threads. I'm sure there are other
trivial things that we need to specify. Say, we also need to provide a
QEMU branch with customised patches on top before we upstream all of
them.

> 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.
> 

It's on our radar. As you said, getting those working would be
beneficial to both Linux-based stubdom and rump kernel stubdom.

Currently getting Raisin to generate image can help a developer to focus
on solving the real problems. I appreciate that a lot.

Wei.

> 
> > Wei.
> >
> > > All the best,
> > > Eric
> > >
> >

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