Re: [Xen-devel] stubdom in 4.3 still based on qemu-traditional?

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Tue, May 7, 2013 at 5:15 PM, Eric Shelton <eshelton@xxxxxxxxx> wrote:
> As far as I can tell, the stubdom code is built using qemu-traditional.
>
> Looking at various Xen 4.3 roadmap emails, it's not clear to me
> whether the plan is for 4.3 to implement stubdom using xen-upstream or
> the new linux-based stubdom (has linux stubdom even been committed?).
>
> I would think that leaving it on qemu-traditional would be the wrong
> choice, given (1) the stated goal of, and many efforts towards,
> transitioning to xen-upstream; and (2) that development efforts, and
> more importantly bug fixes, are almost exclusively being made against
> qemu-upstream, with little, if anything, having been backported in the
> last few months.
>
> If stubdom is to remain on qemu-traditional, someone probably needs to
> review the patches against xen-upstream (going back to when, I do not
> know) to determine if anything should or needs to be backported.  For
> example, should qemu-upstream commit
> 2d9b78b602494464ccae7667e655c962db9c3a65 be backported, as I believe
> stubdom-dm is a PV guest?
>
> A more minor issue is that the stubdom domain is still being created
> using xm instead of xl.
>
> Sorry if this has already been addressed, but it did not turn up in my
> searches of this mailing list.

The term you need to search for is "linux stub domains" or "linux
stubdoms".  I suppose in the future, when big items are taken off the
list, a brief explanation (or at least a reference to a public
conversation) should be included in the release update e-mails.

Thanks for bringing this up -- the decision at this point has been to
postpone qemu-upstream stubdomains until 4.4.  This is definitely not
ideal, but overall we thought it was the bets option.  Let me try to
explain the reasoning.

The basic problem with qemu-upstream as a stubdom is that it requires
libc functionality that is not present in minios.  Two technical
solutions were proposed: the first was porting a more fully-featured
libc (say, a BSD libc) over to minios; the other was to develop a
stubdomain system based on Linux.  Anthony Perard was tasked with
developing the Linux stub domains.  However, much of his time in
January and February was taken up with getting Xen into a demo-able
state on some of our ARM-based systems; ARM servers are going to be a
very important future strategic direction, and the Linaro conference
in HK at the end of February was a very crucial moment for the future
of Xen on ARM.  The good news is that we made a big impact at Linaro
and there is every indication that Xen will be a big player in ARM
servers.  The bad news is that Linux stubdomains were delayed.  He did
post some prototype patches of Linux stub domains a few weeks ago, but
they were not really in a state ready to be released on schedule.

This left us with the option of continuing to use qemu-traditional for
stub domains, or slipping the release by up to a month.  Overall the
decision was that using qemu-traditional for stubdomains for one more
release would not be a terrible thing.  We're probably going to switch
to a shorter release cycle for 4.4 -- probably 6 months; so the delay
shouldn't be too long.

Of course it's not too late to argue that we really should slip the
release; but I think you're going to have to be quite persuasive at
this point. :-)

I'll add "browse qemu-upstream for important fixes to be back-ported
to qemu-traditional" to the release checklist.  If you have some time,
could you go through and look for some changesets you think might be
important, and send them to the list, cc'ing Anthony Perard and
Stefano Stabellini?

Thanks,
 -George

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