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

Ian.

> 
> Fix pc migration from qemu <= 1.5
> 
> - Potential compilation issue:
> Adjust qapi-visit for python-2.4.3
> configure: Explicitly set ARFLAGS so we can build with GNU Make 4.0
> 
> - Memory leak:
> qapi: fix memleak by adding implict struct functions in dealloc visitor
>   qapi is used by qmp, so potential leaks when doing qmp call
> qom: Fix memory leak in object_property_set_link()
>   same for qom
> 
> qdev-monitor: Fix crash when device_add is called with abstract driver
> qdev-monitor: Unref device when device_add fails
>   those could be a potential issue triggered through device-add qmp
>   command
> 
> qemu-char: Fix potential out of bounds access to local arrays
>   for serial="vc:WxH"
>   vc stand for virtual console
> 
> audio: honor QEMU_AUDIO_TIMER_PERIOD instead of waking up every *nano* second
>   looks like it improve cpu load when playing audio
> 
> scsi_target_send_command(): amend stable-1.6 port of the CVE-2013-4344 fix
>   if someone use scsi disk
> 
> vmdk: Fix vmdk_parse_extents
> vmdk: Fix creating big description file
>   if someone use a vmdk disk image
> 
> qcow2: count_contiguous_clusters and compression
> qcow2: fix possible corruption when reading multiple clusters
> qcow2: Zero-initialise first cluster for new images
>   several qcow2 fixes, a file disk format
> 
> virtio-net: only delete bh that existed
> virtio-net: fix the memory leak in rxfilter_notify()
>   few virtio fixes
> 
> rng-egd: offset the point when repeatedly read from the buffer
>   looks like this can be used by virtio
> 
> 
> I did not list the commit that does not look like a Xen guest can use.
> So is this look like patches to take in our tree ? At least the first 7
> would be good to take I think (migration fix, memory leaks, qdev fixes).
> 
> Regards,
> 



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