[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PULL] qemu-xen stable update to 1.6.2



On 01/24/2014 07:34 PM, Stefano Stabellini wrote:
On Fri, 17 Jan 2014, Stefano Stabellini wrote:
On Fri, 17 Jan 2014, Anthony PERARD wrote:
On Fri, Jan 17, 2014 at 01:17:55PM +0000, Stefano Stabellini wrote:
On Fri, 17 Jan 2014, Anthony PERARD wrote:
On Thu, Jan 16, 2014 at 03:51:42PM +0000, Stefano Stabellini wrote:
On Thu, 16 Jan 2014, Anthony PERARD wrote:
On Thu, Jan 16, 2014 at 03:42:17PM +0000, Stefano Stabellini wrote:
On Wed, 15 Jan 2014, Ian Campbell wrote:
On Wed, 2014-01-15 at 14:35 +0000, Anthony PERARD wrote:
On Wed, Jan 15, 2014 at 09:35:10AM +0000, Ian Campbell wrote:
On Tue, 2014-01-14 at 18:52 +0000, Anthony PERARD wrote:
There is an update of QEMU 1.6, I have done a merge and put that in a tree:
git://xenbits.xen.org/people/aperard/qemu-dm.git  merge-1.6.2
Based on the above I have no idea whether a freeze exception should be
granted for this, so my default answer is no. I'm not sure what else you
could have expected.

If you think there are changes here which should be in 4.4.0 then please
enumerate all changes included in this merge which have any relation to
Xen and their potential impact on the release.
I have a list the change here that have a potential impact on Xen, with
the ones that I think are quite important at the beginning. Either the
commit title speak for itself or I added a small description on what is
affected.
Thanks but there's not a lot here for me to go on WRT making a decision
on a freeze exception. Did you refer to
http://wiki.xen.org/wiki/Xen_Roadmap/4.4#Exception_guidelines_for_after_the_code_freeze
like I said? A freeze exception needs an analysis of benefits and risks,
not the very briefest words you can possibly manage.

Anyway it appears this is a grab bag of things we might want and misc
fixes which are perhaps nice to have, I'm nowhere near comfortable
giving it a blanket exemption based on what you've presented here, or
even of cherry picking what might be the important ones. If you think
any or all of it is actually important for 4.4 please make a proper case
for inclusion, either of the aggregate or of the individual changes.
Anthony, did you simply update the tree by pulling from the upstream 1.6
stable tree?
Yes, a simple merge.

I also assume that you tested at the very least the basic
PV and HVM configurations?
:(, no, I haven't try PV. But I did try HVM.

There is one thing that I may want to try, it's migration from the
previous version of Xen. There is one patch that change (fix?) that.
Please do and let me know if it works as expected.
I have tryied a pv guest, it does work fine.

I also try a migration (xl save/restore) from Xen 4.3.1 to Xen 4.4 with
both the current qemu-xen tree and with the merge of 1.6.2, but the
migration fail in both cases because of the same error reported by qemu.
(Unknown savevm section or instance '0000:02.0/cirrus_vga' 0). I did not
investigate in that. Might just be a issue with my compile script ...
(using the wrong qemu-xen tree).
It is important that we identify what is the cause of the problem.
Especially if you think that it could be a "compile script" issue,
because I imagine that if it is, it might invalidate your previous
positive tests too.
I was compiling with always the master branch of qemu-xen. So I had a
Xen 4.3 with QEMU 1.6 instead of 1.3. So it only invalidate the
migration test.
OK, good. Can you double check how migration from  Xen 4.3 with QEMU 1.3
works?
I tested migration myself: although the update fixes a couple of
problems with migration from 1.3, it also introduces a new one, that
fortunately is fixed in QEMU 1.7.0.

I have a branch based on 1.6.2 plus the backported fix from 1.7.0 that
works well, I recommend getting a release exception for it and pushing
it as soon as possible.

Sorry, didn't catch the "I recommend getting a release exception". The qemu issues (including the migration one) are definitely the main blockers to the release at the moment, so:

Release-acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.