Re: [Qemu-devel] [ANNOUNCE] QEMU 1.1-rc2 release

[Stefan Weil <sw@weilnetz.de>]

Am 15.05.2012 18:38, schrieb Anthony Liguori:
> On 05/15/2012 11:33 AM, Stefan Weil wrote:
>> Am 15.05.2012 18:04, schrieb Anthony Liguori:
>>> Hi,
>>>
>>> On behalf of the QEMU Team, I'd like to announce the availability of 
>>> the
>>> second release candidate for the QEMU 1.1 release. This release is 
>>> meant for
>>> testing purposes and should not be used in a production environment.
>>>
>>> http://wiki.qemu.org/download/qemu-1.1.0-rc2.tar.bz2
>>>
>>> You can help improve the quality of the QEMU 1.1 release by testing 
>>> this
>>> release and reporting bugs on Launchpad:
>>>
>>> https://bugs.launchpad.net/qemu/
>>>
>>> The release plan for the 1.1 release is available at:
>>>
>>> http://wiki.qemu.org/Planning/1.1
>>>
>>> And a detailed change log is available at:
>>>
>>> http://wiki.qemu.org/ChangeLog/Next
>>>
>>> Known Issues:
>>>
>>> - There appears to be a failure in make check on some platforms. 
>>> This will be
>>> resolved in -rc3.
>>>
>>
>> Just for the record: there are a lot more known issues.
>> Here is a small extract:
>>
>> - SDL (zooming) and VNC both access uninitialized memory.
>> SDL even writes out of bounds. Valgrind finds both kinds
>> of defects easily.
>>
>> - There are still several known memory leaks. For some of them
>> patches were already sent to qemu-devel.
>>
>> - There are known deficits in the emulations. Even the x86_64
>> system emulation which is one of the best maintained emulations
>> still causes a blue screen when running a 64 bit Windows guest
>> in TCG mode, for example.
>>
>> A lot was already done, but there still remains much work to be done :-)
>
> Yes, there's always more work to do in the future :-)
>
> Known issues == release blockers.  I'm not willing to block a release 
> for uninitialized memory access unless it's be validated by a human 
> (and if it has, there probably will be a patch already).

Well, I believe that I am a human being :-)

I have a (still unpublished) fix for the SDL zooming bug:
newer versions of SDL_rotozoom (which is used in ui/sdl_zoom.c)
no longer show this bug. The patch changes a lot of code,
so it is too risky for 1.1.

A patch which disables zooming (which avoids the bug) was
sent some weeks ago. It could be used for 1.1.

>
> Likewise, memory leaks are not going to block the release unless they 
> are significant.

Agreed. Known leaks with existing patches should be fixed
in the new release.

>
> An TCG deficiencies don't count as a release blocker unless it's a 
> regression.
>
> Regards,
>
> Anthony Liguroi
>
>>
>> Cheers,
>>
>> Stefan Weil