Re: [RFC 7/7] libxl: Wait for QEMU startup in stubdomain

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

On Fri, 6 Feb 2015, Eric Shelton wrote:
> On Fri, Feb 6, 2015 at 10:36 AM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Fri, 6 Feb 2015, Wei Liu wrote:
> 
> >> ISTR our policy is upstream first. That is, though we maintain our own
> >> qemu tree those changesets are all upstream changesets. Arguably there
> >> might be some bandaid changesets that are not upstream but big changes
> >> like this needs to be upstreamed first.
> >>
> >> Stefano, could you clarify this and correct me if I'm wrong?
> >
> > Yes, the policy is upstream first, however it doesn't need to land in a
> > QEMU release. Just be upstream.
> >
> > There is still please of time for that: Eric just needs to send his
> > patches to qemu-devel, get the acks, and I'll apply to
> > qemu-xen-upstream.
> 
> Sounds good.  I think the main thing I am looking at before going to
> qemu-devel is getting the xenfb-based display code up and running.
> However, QEMU is a somewhat unfamiliar codebase for me, and it doesn't
> help that QEMU's display pipeline seems to have been rearchitected a
> time or two since QEMU 0.10, as it seems to limit QEMU-traditional's
> utility as a prototype to follow.  If anyone was any ideas what the
> missing links are for the display pipeline, I would appreciate any
> pointers.

Firstly I would check that xenfb is working without QEMU.

Then I would try to get access to QEMU to the framebuffer using
something like directfb:

https://lists.gnu.org/archive/html/qemu-devel/2010-05/msg01201.html

Or the directfb driver in libsdl.


> >> > > So my hunch is that we're not going to make it in time for
> >> > > 4.6. :-/
> >> > >
> >> > > Wei.
> >> >
> >> > 4.5 was _just_ released, and Xen is on a ~10 month release cycle.  Why
> >> > can't this get done?  Someone just has to take a little time to sit
> >>
> >> Notably there are many months that are code freeze.
> >>
> >> And due to our upstream first QEMU policy we would also need to upstream
> >> changes to QEMU.
> >
> > Getting the patches upstream in QEMU shouldn't take longer than getting
> > them upstream in Xen.
> >
> > Also I think upstream QEMU stubdoms would be valuable even without
> > save/restore support.
> 
> Good to hear.  As I mentioned when I posted the patches, I am guessing
> QMP, which appears to be needed for save/restore among other things,
> is going to present some headaches if there are any commands that will
> require coordination of both the stubdom- and Dom0-side instances of
> QEMU for completion.  Anyway, I doubt I am the right person to tackle
> save/restore - it's not a feature I make use of at all.

fair enough


> >> > Can we arrive at an agreement that a Linux-based QEMU-upstream stubdom
> >> > should _at least_ be a technical preview for Xen 4.6?  A year ago,
> >
> > I agree. Or rumpkernel-based QEMU-upstream stubdom. Or something.
> 
> >> If we really want to make this happen before new protocol and
> >> implementation are in place.  That would be "tech preview" or
> >> "experimental", whichever is the term for least mature technology. Note
> >> that this is not due to the route it chooses (Linux based), it's due to
> >> the fact that the protocol is broken and destined to be changed.
> >
> > I think we should not block the entire upstream stubdom effort, whether
> > it is Linux, MiniOS or Rumpkernel based, waiting for the bootup protocol
> > to be fixed.
> >
> > The two things can and should be done in parallel.
> 
> Great; I think we should be able to make this happen for 4.6.
> 
> One of the main issues outstanding from when Anthony originally posted
> his patches is how we want to go about building this?  I honestly do
> not know how well the current dracut-based approach to building the
> root image will work across various Linux distributions; perhaps it
> will be OK, since all of the libraries that dracut will siphon in will
> have to be in place to meet the build requirements for QEMU to begin
> with. 
>
> However, I have zero knowledge about ARM-based Xen or where
> NetBSD is used for dom0, and how they might affect the decisionmaking.
> I also do not know what lessons have been learned from building other
> stubdoms, rumpkernel, or Mirage that might inform these decisions.
> In other words, what do you see as a sensible build scheme?  The
> approach taken in the patches strikes me as too hacky for release
> quality, but maybe it is OK...
 
It looks OK to me but I am not an expert in this kind of things. I'll
let Ian Campbell and Ian Jackson (CC'ed) comment on it.