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

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

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

Changes since -rc1:

  - tcg/ppc64: Fix CONFIG_TCG_PASS_AREG0 (Andreas Färber)
  - tcg/ppc64: Don't hardcode register numbers for qemu_ld/st (Andreas Färber)
  - qdev: fix -device foo,? (Paolo Bonzini)
  - qemu-img: Fix segmentation fault (Charles Arnold)
  - qcow2: Don't ignore failure to clear autoclear flags (Kevin Wolf)
  - coroutine: Fix setup of sigaltstack coroutines (Jan Kiszka)
  - qapi: QMP input visitor, handle floats parsed as ints (Michael Roth)
  - usb-host: handle guest-issued clear halt (Gerd Hoffmann)
  - qxl: set size of PCI IO BAR correctly (16) for revision 2 (Uri Lublin)
  - qemu-doc: Use QEMU instead of qemu for product name (Stefan Weil)
  - qemu-doc: Fix executable name in examples (Stefan Weil)
  - qemu-doc: Add missing parameter in description of -D option (Stefan Weil)
  - configure: Use QEMU instead of Qemu (Stefan Weil)
  - fix some common typos (Jim Meyering)
  - qemu-timer: Fix wrong error message (Stefan Weil)
  - mips_fulong2e: Don't register "cpu" VMState twice (Juan Quintela)
  - pc: Add back PCI.rombar compat property (Paolo Bonzini)
  - qdev: Fix adding of ptr properties (Anthony Liguori)
  - qdev: Use object_property_print() in info qtree (Paolo Bonzini)
  - target-i386: Defer MCE init (Andreas Färber)
  - qom: Documentation addition for object_class_by_name() (Paolo Bonzini)
  - target-mips: Remove commented-out function declaration (Andreas Färber)
  - sun4u: implement interrupt clearing registers (Artyom Tarasenko)
  - sun4u: initialize OBIO interrupt mappings (Artyom Tarasenko)
  - fix block loads broken in commit 30038fd818 (Artyom Tarasenko)
  - Implement address masking for SPARC v9 CPUs (Artyom Tarasenko)
  - vga: disable default VGA if appropriate -device is used (Paolo Bonzini)
  - cputlb: fix watchpoints handling (Max Filippov)
  - use inet_listen()/inet_connect() to support ipv6 migration (Amos Kong)
  - sockets: use error class to pass listen error (Amos Kong)
  - sockets: change inet_connect() to support nonblock socket (Amos Kong)
  - qerror: add five qerror strings (Amos Kong)
  - move CPU definitions to /usr/share/qemu/cpus-x86_64.conf (v2) (Eduardo Habkost)
  - implement -no-user-config command-line option (v3) (Eduardo Habkost)
  - vl.c: change 'defconfig' variable to bool (v2) (Eduardo Habkost)
  - move list of default config files to an array (Eduardo Habkost)
  - eliminate arch_config_name variable (Eduardo Habkost)
  - move code to read default config files to a separate function (v2) (Eduardo 
Habkost)
  - block: fix warning introduced in efcc7a23 (Anthony Liguori)
  - Switch SIG_IPI to SIGUSR1 (Jan Kiszka)
  - target-arm/cpu.h: Make cpu_init("nonexistent cpu") return NULL (Peter Maydell)
  - target-arm: When setting FPSCR.QC, don't clear other FPSCR bits (Matt Craighead)
  - kvm: Fix dirty tracking with large kernel page size (David Gibson)
  - declare ECANCELED on all machines (Paolo Bonzini)
  - tests/Makefile: Add missing $(EXESUF) (Kevin Wolf)
  - stream: do not copy unallocated sectors from the base (Paolo Bonzini)
  - stream: fix ratelimiting corner case (Paolo Bonzini)
  - stream: fix HMP block_job_set_speed (Paolo Bonzini)
  - stream: pass new base image format to bdrv_change_backing_file (Paolo Bonzini)
  - stream: add testcase for partial streaming (Paolo Bonzini)
  - stream: fix sectors not allocated test (Paolo Bonzini)
  - qemu-io: fix the alloc command (Paolo Bonzini)
  - qemu-io: correctly print non-integer values as decimals (Paolo Bonzini)
  - qemu-img: make "info" backing file output correct and easier to use (Paolo 
Bonzini)
  - block: move field reset from bdrv_open_common to bdrv_close (Paolo Bonzini)
  - block: protect path_has_protocol from filenames with colons (Paolo Bonzini)
  - block: simplify path_is_absolute (Paolo Bonzini)
  - block: wait for job callback in block_job_cancel_sync (Paolo Bonzini)
  - block: add block_job_sleep_ns (Paolo Bonzini)
  - block: fully delete bs->file when closing (Paolo Bonzini)
  - block: do not reuse the backing file across bdrv_close/bdrv_open (Paolo Bonzini)
  - block: another bdrv_append fix (Paolo Bonzini)
  - block: fix snapshot on QED (Paolo Bonzini)
  - qtest: Add floppy test (Kevin Wolf)
  - qtest: Add function to send QMP commands (Kevin Wolf)
  - qemu-iotests: strip spaces from qemu-img/qemu-io/qemu command lines (Paolo 
Bonzini)
  - block: fix allocation size for dirty bitmap (Paolo Bonzini)
  - block: open backing file as read-only when probing for size (Paolo Bonzini)
  - block: update in-memory backing file and format (Paolo Bonzini)
  - block: push bdrv_change_backing_file error checking up from drivers (Paolo 
Bonzini)
  - block: fail live snapshot if disk has no medium (Paolo Bonzini)
  - block: add mode argument to blockdev-snapshot-sync (Paolo Bonzini)
  - block: add the support to drain throttled requests (Zhi Yong Wu)

Regards,

Anthony Liguori

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

[Stefan Weil]

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 :-)

Cheers,

Stefan Weil

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

[Andreas Färber]

Am 15.05.2012 18:04, schrieb Anthony Liguori:
> 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

Why does the numbering scheme constantly change? :)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

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

[Peter Maydell]

On 15 May 2012 17:33, Stefan Weil <sw@weilnetz.de> wrote:
> Am 15.05.2012 18:04, schrieb Anthony Liguori:
>> 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 :-)

Alex's linux-user stale-tbs-after-mmap patch is also still pending.

Maybe we should record patches/series/bugs that we hope to get into
the release on the wiki page, so it's easier to construct this
"known issues" list and Anthony has a checklist of things that
might have been accidentally passed over?

-- PMM

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

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

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

An TCG deficiencies don't count as a release blocker unless it's a regression.

Regards,

Anthony Liguroi

>
> Cheers,
>
> Stefan Weil
>
>

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

[Anthony Liguori]

On 05/15/2012 11:38 AM, Peter Maydell wrote:
> On 15 May 2012 17:33, Stefan Weil<sw@weilnetz.de>  wrote:
>> Am 15.05.2012 18:04, schrieb Anthony Liguori:
>>> 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 :-)
>
> Alex's linux-user stale-tbs-after-mmap patch is also still pending.

Does Riku have it queued?

I saw that patch and expected it to come from Riku's tree..

Regards,

Anthony Liguori

>
> Maybe we should record patches/series/bugs that we hope to get into
> the release on the wiki page, so it's easier to construct this
> "known issues" list and Anthony has a checklist of things that
> might have been accidentally passed over?
>
> -- PMM
>

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

[Peter Maydell]

On 15 May 2012 17:38, Anthony Liguori <anthony@codemonkey.ws> wrote:
> 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).
>
> Likewise, memory leaks are not going to block the release unless they are
> significant.
>
> An TCG deficiencies don't count as a release blocker unless it's a
> regression.

In this case it is a regression...

Anyway, my point is not "these things must go in" but that it's very
hard to tell from this side whether a patch is in the state:
 (a) in your queue and will go into this rc
 (b) missed the boat for this rc but will be in the next
 (c) completely overlooked and needs pinging/yelling about
 (d) judged not important enough to justify fixing in this release

The usual "assume it's gone into somebody's tree and ping again
in a week or two" doesn't work when release candidates are done
on a schedule of every week or so, you need a more positive ack
and tracking IMHO.

-- PMM

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

[Anthony Liguori]

On 05/15/2012 11:37 AM, Andreas Färber wrote:
> Am 15.05.2012 18:04, schrieb Anthony Liguori:
>> 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
>
> Why does the numbering scheme constantly change? :)

I was just about to send a heads up note about this :-)

I started out following the 1.0 numbering scheme but decided that this is 
causing more trouble than it's worth.

So starting with -rc2, all numbering is going to follow x.y.z.  There is a 
v1.1-rc2 and a v1.1.0-rc2 tag just to help with the transition but expect 1.1 to 
go out with the full x.y.z versioning.

Regards,

Anthony Liguori

>
> Andreas
>

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

[Stefan Weil]

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

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

[Anthony Liguori]

On 05/15/2012 11:42 AM, Peter Maydell wrote:
> On 15 May 2012 17:38, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> 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).
>>
>> Likewise, memory leaks are not going to block the release unless they are
>> significant.
>>
>> An TCG deficiencies don't count as a release blocker unless it's a
>> regression.
>
> In this case it is a regression...

At what point did it regress?  I don't recall win64 ever working uner TCG...

> Anyway, my point is not "these things must go in" but that it's very
> hard to tell from this side whether a patch is in the state:
>   (a) in your queue and will go into this rc
>   (b) missed the boat for this rc but will be in the next
>   (c) completely overlooked and needs pinging/yelling about
>   (d) judged not important enough to justify fixing in this release

It's it not tagged '1.1' than I am not considering it for 1.1.

If it's tagged with 1.1 *and* in a subsystem with an active submaintainer, I 
would expect the submaintainer to handle it.  I do keep track of it though until 
someone responds with "Thanks, Applied." and will follow up with patches that 
fall into this category.

> The usual "assume it's gone into somebody's tree and ping again
> in a week or two" doesn't work when release candidates are done
> on a schedule of every week or so, you need a more positive ack
> and tracking IMHO.

If you've posted a patch for 1.1 and it's a couple days old without feedback, 
then you probably should ping the appropriate maintainer about it.

FWIW, I don't see any pending 1.1 patches from you so I don't know if this is a 
theoretical concern or a practical one.

Regards,

Anthony Liguori

>
> -- PMM

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

[Peter Maydell]

On 15 May 2012 21:20, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 05/15/2012 11:42 AM, Peter Maydell wrote:
>> In this case it is a regression...

> At what point did it regress?  I don't recall win64 ever working uner TCG...

Sorry, I had in mind the mmap thing, and got confused with what
I was quoting.

>> Anyway, my point is not "these things must go in" but that it's very
>> hard to tell from this side whether a patch is in the state:
>>  (a) in your queue and will go into this rc
>>  (b) missed the boat for this rc but will be in the next
>>  (c) completely overlooked and needs pinging/yelling about
>>  (d) judged not important enough to justify fixing in this release
>
> It's it not tagged '1.1' than I am not considering it for 1.1.
>
> If it's tagged with 1.1 *and* in a subsystem with an active submaintainer, I
> would expect the submaintainer to handle it.  I do keep track of it though
> until someone responds with "Thanks, Applied." and will follow up with
> patches that fall into this category.

> If you've posted a patch for 1.1 and it's a couple days old without
> feedback, then you probably should ping the appropriate maintainer about it.
>
> FWIW, I don't see any pending 1.1 patches from you so I don't know if this
> is a theoretical concern or a practical one.

My current concern is
http://patchwork.ozlabs.org/patch/158556/
(submitted by Alex, although I see he forgot to tag it with "1.1").

I'll ping it...

-- PMM

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

[Andreas Färber]

Am 15.05.2012 22:33, schrieb Peter Maydell:
> On 15 May 2012 21:20, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> [If it's] not tagged '1.1' than I am not considering it for 1.1.
>>
>> If it's tagged with 1.1 *and* in a subsystem with an active submaintainer, I
>> would expect the submaintainer to handle it.  I do keep track of it though
>> until someone responds with "Thanks, Applied." and will follow up with
>> patches that fall into this category.
> 
>> If you've posted a patch for 1.1 and it's a couple days old without
>> feedback, then you probably should ping the appropriate maintainer about it.
>>
>> FWIW, I don't see any pending 1.1 patches from you so I don't know if this
>> is a theoretical concern or a practical one.
> 
> My current concern is
> http://patchwork.ozlabs.org/patch/158556/
> (submitted by Alex, although I see he forgot to tag it with "1.1").

Also forgot "v2" fwiw. ;)

> 
> I'll ping it...
> 
> -- PMM

/-F

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

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

[Blue Swirl]

On Tue, May 15, 2012 at 8:33 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 15 May 2012 21:20, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> On 05/15/2012 11:42 AM, Peter Maydell wrote:
>>> In this case it is a regression...
>
>> At what point did it regress?  I don't recall win64 ever working uner TCG...
>
> Sorry, I had in mind the mmap thing, and got confused with what
> I was quoting.
>
>>> Anyway, my point is not "these things must go in" but that it's very
>>> hard to tell from this side whether a patch is in the state:
>>>  (a) in your queue and will go into this rc
>>>  (b) missed the boat for this rc but will be in the next
>>>  (c) completely overlooked and needs pinging/yelling about
>>>  (d) judged not important enough to justify fixing in this release
>>
>> It's it not tagged '1.1' than I am not considering it for 1.1.
>>
>> If it's tagged with 1.1 *and* in a subsystem with an active submaintainer, I
>> would expect the submaintainer to handle it.  I do keep track of it though
>> until someone responds with "Thanks, Applied." and will follow up with
>> patches that fall into this category.
>
>> If you've posted a patch for 1.1 and it's a couple days old without
>> feedback, then you probably should ping the appropriate maintainer about it.
>>
>> FWIW, I don't see any pending 1.1 patches from you so I don't know if this
>> is a theoretical concern or a practical one.
>
> My current concern is
> http://patchwork.ozlabs.org/patch/158556/
> (submitted by Alex, although I see he forgot to tag it with "1.1").

Thanks, applied.

>
> I'll ping it...
>
> -- PMM
>