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

[Eric Shelton <eshelton@xxxxxxxxx>]

On Fri, Feb 6, 2015 at 10:36 AM, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> 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.

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

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

- Eric

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