[Qemu-devel] [ANNOUNCE] QEMU 2.1.0-rc2 is now available

[Qemu-devel] [ANNOUNCE] QEMU 2.1.0-rc2 is now available

[Michael Roth]

Hello,

On behalf of the QEMU Team, I'd like to announce the availability of the
third release candidate for the QEMU 2.1 release.  This release is meant
for testing purposes and should not be used in a production environment.

  http://wiki.qemu.org/download/qemu-2.1.0-rc2.tar.bz2

You can help improve the quality of the QEMU 2.1 release by testing this
release and reporting bugs on Launchpad:

  https://bugs.launchpad.net/qemu/

The release plan for the 2.1 release is available at:

  http://wiki.qemu.org/Planning/2.1

Please add entries to the ChangeLog for the 2.1 release below:

  http://wiki.qemu.org/ChangeLog/2.1

The following changes have been made since v2.1.0-rc1:

5a73480: Update version for v2.1.0-rc2 release (Peter Maydell)
82172b7: tests/Makefile: Only run vhost-user-test on Linux (Peter Maydell)
27e2778: sPAPR/IOMMU: Fix TCE entry permission (Gavin Shan)
f92f5da: spapr: Enable use of huge pages (Alexey Kardashevskiy)
658fa66: spapr: Move RMA memory region registration code (Alexey Kardashevskiy)
e938ba0: ppc: memory: Replace memory_region_init_ram with memory_region_allocate_system_memory (Shreyas B. Prabhu)
063cac5: target-ppc: Fix number of threads per core limit (Alexey Kardashevskiy)
b545f63: linux-user: use TARGET_SA_ONSTACK in get_sigframe (Riku Voipio)
5b2ffbe: virtio-blk: dataplane: notify guest as a batch (Ming Lei)
e926d9b: virtio-blk: data-plane: fix save/set .complete_request in start (Ming Lei)
a1abf40: linux-aio: Fix laio resource leak (Gonglei)
2dd08df: alloca one extra byte sockets (Joakim Tjernlund)
33a29b5: linux-user: handle AF_PACKET sockaddrs in target_to_host_sockaddr (Joakim Tjernlund)
451aaf6: qemu-user: Impl. setsockopt(SO_BINDTODEVICE) (Joakim Tjernlund)
27a0782: SIOCGIFINDEX: fix typo (Joakim Tjernlund)
0e16297: libqos: Fix PC PCI endianness glitches (Andreas Färber)
7497bce: serial-pci: remove memory regions from BAR before destroying them (Paolo Bonzini)
1f4e6a0: virtio-scsi: fix with -M pc-i440fx-2.0 (Paolo Bonzini)
f702e62: serial: change retry logic to avoid concurrency (Kirill Batuzov)
7b3621f: qemu-char: fix deadlock with "-monitor pty" (Paolo Bonzini)
58ac321: ide: Treat read/write beyond end as invalid (Markus Armbruster)
3c2daac: virtio-blk: Treat read/write beyond end as invalid (Markus Armbruster)
42e38c1: virtio-blk: Bypass error action and I/O accounting on invalid r/w (Markus Armbruster)
d0e1437: virtio-blk: Factor common checks out of virtio_blk_handle_read/write() (Markus Armbruster)
58f423f: dma-helpers: Fix too long qiov (Kevin Wolf)
80504dc: qtest: fix vhost-user-test compilation with old GLib (Nikolay Nikolaev)
b886424: tests: Fix unterminated string output visitor enum human string (Andreas Färber)
acfb23a: AioContext: do not rely on aio_poll(ctx, true) result to end a loop (Paolo Bonzini)
f897bf7: virtio-blk: embed VirtQueueElement in VirtIOBlockReq (Stefan Hajnoczi)
869d66a: virtio-blk: avoid g_slice_new0() for VirtIOBlockReq and VirtQueueElement (Stefan Hajnoczi)
abd7642: dataplane: do not free VirtQueueElement in vring_push() (Stefan Hajnoczi)
0a21ea3: virtio-blk: avoid dataplane VirtIOBlockReq early free (Stefan Hajnoczi)
8eb029c: block: Assert qiov length matches request length (Kevin Wolf)
f06ee3d: qed: Make qiov match request size until backing file EOF (Kevin Wolf)
44deba5: qcow2: Make qiov match request size until backing file EOF (Kevin Wolf)
33f461e: block: Make qiov match the request size until EOF (Kevin Wolf)
2039511: scsi: Report error when lun number is in use (Fam Zheng)
85ad623: s390x/kvm: synchronize guest floating point registers (Jason J. Herne)
13d5412: mtp: linux guest detection fix. (Gerd Hoffmann)
e72b59f: ui/gtk: Restore keyboard focus after Page change (John Snow)
d16136d: cirrus: Fix host CPU blits (Benjamin Herrenschmidt)
e8ee4b6: cirrus: Fix build of debug code (Benjamin Herrenschmidt)
f61d82c: cirrus_vga: adding sanity check for vram size (Gonglei)
b1ea7b7: spice: auth fixes (Gerd Hoffmann)
0a58991: qtest: fix vhost-user-test compilation with old GLib (Nikolay Nikolaev)
13c0cba: mc146818rtc: register the clock reset notifier on the right clock (Paolo Bonzini)
b7bf8f5: oslib-posix: Fix new compiler error with -Wclobbered (Stefan Weil)
8248c36: target-i386: Add "kvmclock-stable-bit" feature bit name (Eduardo Habkost)
3b463a3: Enforce stack protector usage (Miroslav Rezanina)
9e99c5f: tests: Fix unterminated string output visitor enum human string (Andreas Färber)
30e5210: watchdog: fix deadlock with -watchdog-action pause (Paolo Bonzini)
f7f1524: mips_malta: Catch kernels linked at wrong address (James Hogan)
fbdb1d9: mips_malta: Remove incorrect KVM T&E references (James Hogan)
0e928b1: mips/kvm: Disable FPU on reset with KVM (James Hogan)
0ceb849: AioContext: speed up aio_notify (Paolo Bonzini)
ef508f4: test-aio: fix GSource-based timer test (Paolo Bonzini)
87f68d3: block: drop aio functions that operate on the main AioContext (Paolo Bonzini)
b47ec2c: block: prefer aio_poll to qemu_aio_wait (Paolo Bonzini)
01fb270: block: Fix bdrv_is_allocated() return value (Kevin Wolf)
d40593d: block/backup: Fix hang for unaligned image size (Kevin Wolf)
0a2672b: mips/kvm: Init EBase to correct KSEG0 (James Hogan)

[Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases (was: [ANNOUNCE] QEMU 2.1.0-rc2 is now available)

[Stefan Weil]

Am 16.07.2014 02:26, schrieb Michael Roth:
> Hello,
>
> On behalf of the QEMU Team, I'd like to announce the availability of the
> third release candidate for the QEMU 2.1 release.  This release is meant
> for testing purposes and should not be used in a production environment.
>
>   http://wiki.qemu.org/download/qemu-2.1.0-rc2.tar.bz2
>
> You can help improve the quality of the QEMU 2.1 release by testing this
> release and reporting bugs on Launchpad:
>
>   https://bugs.launchpad.net/qemu/

Hi,

a recent commit (e49ab19fcaa617ad6cdfe1ac401327326b6a2552) increased the
requirements for libiscsi from 1.4.0 to 1.9.0. From a user's point of
view, this change results in a regression for Debian and similar Linux
distributions: QEMU no longer includes iscsi features.

In this special case, the current Debian stable includes QEMU packages
with libiscsi 1.4, but new builds won't include it because that version
is now too old. Debian testing includes a brand new libiscsi, but it
does not include libiscsi.pc, so pkg-config won't know that it is
available and configure will disable libiscsi. I have a patch which
fixes this, so QEMU for Debian testing could include libiscsi again.

Is a feature regression like this one acceptable? Do we need additional
testing (maybe run the build bots with --enable-xxx, so builds fail when
xxx no longer works)?

Regards
Stefan

Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases (was: [ANNOUNCE] QEMU 2.1.0-rc2 is now available)

[Peter Maydell]

On 16 July 2014 17:28, Stefan Weil <sw@weilnetz.de> wrote:
> a recent commit (e49ab19fcaa617ad6cdfe1ac401327326b6a2552) increased the
> requirements for libiscsi from 1.4.0 to 1.9.0. From a user's point of
> view, this change results in a regression for Debian and similar Linux
> distributions: QEMU no longer includes iscsi features.
>
> In this special case, the current Debian stable includes QEMU packages
> with libiscsi 1.4, but new builds won't include it because that version
> is now too old. Debian testing includes a brand new libiscsi, but it
> does not include libiscsi.pc, so pkg-config won't know that it is
> available and configure will disable libiscsi. I have a patch which
> fixes this, so QEMU for Debian testing could include libiscsi again.
>
> Is a feature regression like this one acceptable? Do we need additional
> testing (maybe run the build bots with --enable-xxx, so builds fail when
> xxx no longer works)?

In general, we should try to avoid feature regressions, but it's
going to be a case-by-case thing. In this particular instance,
upstream libiscsi don't recommend pre-1.9 for production use
(as the commit message documents), and I don't think we would
be doing our users any favours by allowing them to build something
that's likely to be broken. We should of course flag up this sort of
"minimum version of our dependencies has been bumped" info in
the release notes.

I think that "does QEMU still build with all the features we need on
our distro?" has to be testing done by the people who package and
maintain QEMU for each distro -- they're the only people who know
which configurations options they enable and which baseline versions
of their distro they still care about packaging mainline QEMU for.

thanks
-- PMM

Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases

[Peter Lieven]

Am 16.07.2014 18:46, schrieb Peter Maydell:
> On 16 July 2014 17:28, Stefan Weil <sw@weilnetz.de> wrote:
>> a recent commit (e49ab19fcaa617ad6cdfe1ac401327326b6a2552) increased the
>> requirements for libiscsi from 1.4.0 to 1.9.0. From a user's point of
>> view, this change results in a regression for Debian and similar Linux
>> distributions: QEMU no longer includes iscsi features.
>>
>> In this special case, the current Debian stable includes QEMU packages
>> with libiscsi 1.4, but new builds won't include it because that version
>> is now too old. Debian testing includes a brand new libiscsi, but it
>> does not include libiscsi.pc, so pkg-config won't know that it is
>> available and configure will disable libiscsi. I have a patch which
>> fixes this, so QEMU for Debian testing could include libiscsi again.
>>
>> Is a feature regression like this one acceptable? Do we need additional
>> testing (maybe run the build bots with --enable-xxx, so builds fail when
>> xxx no longer works)?
> In general, we should try to avoid feature regressions, but it's
> going to be a case-by-case thing. In this particular instance,
> upstream libiscsi don't recommend pre-1.9 for production use
> (as the commit message documents), and I don't think we would
> be doing our users any favours by allowing them to build something
> that's likely to be broken. We should of course flag up this sort of
> "minimum version of our dependencies has been bumped" info in
> the release notes.

I will update the Wiki.

Peter

>
> I think that "does QEMU still build with all the features we need on
> our distro?" has to be testing done by the people who package and
> maintain QEMU for each distro -- they're the only people who know
> which configurations options they enable and which baseline versions
> of their distro they still care about packaging mainline QEMU for.
>
> thanks
> -- PMM

Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases

[Paolo Bonzini]

Il 16/07/2014 18:28, Stefan Weil ha scritto:
> Debian testing includes a brand new libiscsi, but it
> does not include libiscsi.pc, so pkg-config won't know that it is
> available and configure will disable libiscsi.

That's a packaging bug.

> I have a patch which
> fixes this, so QEMU for Debian testing could include libiscsi again.
>
> Is a feature regression like this one acceptable? Do we need additional
> testing (maybe run the build bots with --enable-xxx, so builds fail when
> xxx no longer works)?

As mentioned in the e49ab19fcaa617ad6cdfe1ac401327326b6a2552 commit 
message, this was intentional.  I was reluctant to do it, but ultimately 
Peter Lieven convinced me that it isn't just about using fancy new APIs; 
libiscsi was too buggy to be useful until release 1.8.0 (even 1.9.0 
requires a patch to avoid segfaults, and many more if you want to run it 
on ARM).

Paolo

Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases

[Stefan Weil]

Am 16.07.2014 18:49, schrieb Paolo Bonzini:
> Il 16/07/2014 18:28, Stefan Weil ha scritto:
>> Debian testing includes a brand new libiscsi, but it
>> does not include libiscsi.pc, so pkg-config won't know that it is
>> available and configure will disable libiscsi.
> 
> That's a packaging bug.

CC'ing Michael as he is the Debian maintainer of this package and
Aurélien who maintains QEMU for Debian.

Michael, should I send a Debian bug report for libiscsi-dev? Would an
update of libiscsi for Debian stable be reasonable if versions older
than 1.9 are too buggy to be used? I must admit that I'm a little bit
surprised because iSCSI support worked for me quite well the last time I
used it with Debian wheezy.

Regards
Stefan

> 
>> I have a patch which
>> fixes this, so QEMU for Debian testing could include libiscsi again.
>>
>> Is a feature regression like this one acceptable? Do we need additional
>> testing (maybe run the build bots with --enable-xxx, so builds fail when
>> xxx no longer works)?
> 
> As mentioned in the e49ab19fcaa617ad6cdfe1ac401327326b6a2552 commit
> message, this was intentional.  I was reluctant to do it, but ultimately
> Peter Lieven convinced me that it isn't just about using fancy new APIs;
> libiscsi was too buggy to be useful until release 1.8.0 (even 1.9.0
> requires a patch to avoid segfaults, and many more if you want to run it
> on ARM).
> 
> Paolo

Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases

[ronnie sahlberg]

On Wed, Jul 16, 2014 at 10:11 AM, Stefan Weil <sw@weilnetz.de> wrote:
> Am 16.07.2014 18:49, schrieb Paolo Bonzini:
>> Il 16/07/2014 18:28, Stefan Weil ha scritto:
>>> Debian testing includes a brand new libiscsi, but it
>>> does not include libiscsi.pc, so pkg-config won't know that it is
>>> available and configure will disable libiscsi.
>>
>> That's a packaging bug.
>
> CC'ing Michael as he is the Debian maintainer of this package and
> Aurélien who maintains QEMU for Debian.
>
> Michael, should I send a Debian bug report for libiscsi-dev? Would an
> update of libiscsi for Debian stable be reasonable if versions older
> than 1.9 are too buggy to be used?

If you ask debian to upgrade. Could you ask them to wait and upgrade after I
have release the next version, hopefully if all goes well, at the end
of this week?

It contains new functionality, thanks to plieven, to better handle
cases where active/passive storage arrays
perform failover.


> I must admit that I'm a little bit
> surprised because iSCSI support worked for me quite well the last time I
> used it with Debian wheezy.

I think, and plieven please correct me if I am wrong, earlier version
would work reasonably well for basic use
but there were bugs and gaps in functionality that made it ill suited
for enterprise environments.

>
> Regards
> Stefan
>
>>
>>> I have a patch which
>>> fixes this, so QEMU for Debian testing could include libiscsi again.
>>>
>>> Is a feature regression like this one acceptable? Do we need additional
>>> testing (maybe run the build bots with --enable-xxx, so builds fail when
>>> xxx no longer works)?
>>
>> As mentioned in the e49ab19fcaa617ad6cdfe1ac401327326b6a2552 commit
>> message, this was intentional.  I was reluctant to do it, but ultimately
>> Peter Lieven convinced me that it isn't just about using fancy new APIs;
>> libiscsi was too buggy to be useful until release 1.8.0 (even 1.9.0
>> requires a patch to avoid segfaults, and many more if you want to run it
>> on ARM).
>>
>> Paolo
>
>

Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases

[Michael Tokarev]

16.07.2014 21:23, ronnie sahlberg wrote:

> If you ask debian to upgrade. Could you ask them to wait and upgrade after I
> have release the next version, hopefully if all goes well, at the end
> of this week?

There's no problem in updating now to fix missing .pc file and to update
next week to include a new version.

Thanks,

/mjt

Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases

[ronnie sahlberg]

On Wed, Jul 16, 2014 at 10:29 AM, Michael Tokarev <mjt@tls.msk.ru> wrote:
> 16.07.2014 21:23, ronnie sahlberg wrote:
>
>> If you ask debian to upgrade. Could you ask them to wait and upgrade after I
>> have release the next version, hopefully if all goes well, at the end
>> of this week?
>
> There's no problem in updating now to fix missing .pc file and to update
> next week to include a new version.
>

Please find a new version 1.12 on the website.

Thanks.
ronnie sahlberg

Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases

[Michael Tokarev]

24.07.2014 04:37, ronnie sahlberg wrote:
> Please find a new version 1.12 on the website.

I'm subscribed to the iscsi mailing list, FWIW.

Thanks,

/mjt

Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases

[Peter Lieven]

Am 16.07.2014 19:23, schrieb ronnie sahlberg:
> On Wed, Jul 16, 2014 at 10:11 AM, Stefan Weil <sw@weilnetz.de> wrote:
>> Am 16.07.2014 18:49, schrieb Paolo Bonzini:
>>> Il 16/07/2014 18:28, Stefan Weil ha scritto:
>>>> Debian testing includes a brand new libiscsi, but it
>>>> does not include libiscsi.pc, so pkg-config won't know that it is
>>>> available and configure will disable libiscsi.
>>> That's a packaging bug.
>> CC'ing Michael as he is the Debian maintainer of this package and
>> Aurélien who maintains QEMU for Debian.
>>
>> Michael, should I send a Debian bug report for libiscsi-dev? Would an
>> update of libiscsi for Debian stable be reasonable if versions older
>> than 1.9 are too buggy to be used?
> If you ask debian to upgrade. Could you ask them to wait and upgrade after I
> have release the next version, hopefully if all goes well, at the end
> of this week?

If someone from Ubuntu reads here, this is also for you. Your latest
LTS release does also contain 1.4.0.

>
> It contains new functionality, thanks to plieven, to better handle
> cases where active/passive storage arrays
> perform failover.

Yes and it fixes yet another bug in serial logic. Not a big one, but it
could cause protocol errors.

>
>
>> I must admit that I'm a little bit
>> surprised because iSCSI support worked for me quite well the last time I
>> used it with Debian wheezy.
> I think, and plieven please correct me if I am wrong, earlier version
> would work reasonably well for basic use
> but there were bugs and gaps in functionality that made it ill suited
> for enterprise environments.

It depends how you define basic use. It causes severe protocol violations especially
on reconnects and it will simply stop sending PDUs if CmdSN wraps from 0xffffffff to 0x0.
Thats ok for try and mount an iSCSI volume and see if it works, but its
not usable for production use enterprise or not.

I mentioned the most critical bugs in the commit message to the libiscsi
version bump to 1.8.0 (which Paolo later increased to 1.9.0 to make the
BUSY handling possible).

Peter

Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases

[Michael Tokarev]

16.07.2014 21:11, Stefan Weil wrote:
> Am 16.07.2014 18:49, schrieb Paolo Bonzini:
>> Il 16/07/2014 18:28, Stefan Weil ha scritto:
>>> Debian testing includes a brand new libiscsi, but it
>>> does not include libiscsi.pc, so pkg-config won't know that it is
>>> available and configure will disable libiscsi.
>>
>> That's a packaging bug.
> 
> CC'ing Michael as he is the Debian maintainer of this package and
> Aurélien who maintains QEMU for Debian.

Actually I maintain both for several years.

> Michael, should I send a Debian bug report for libiscsi-dev? Would an
> update of libiscsi for Debian stable be reasonable if versions older
> than 1.9 are too buggy to be used? I must admit that I'm a little bit
> surprised because iSCSI support worked for me quite well the last time I
> used it with Debian wheezy.

The bug is indeed in libiscsi-dev debian package in testing/jessie, I
forgot to include the .pc file.  Since so far, qemu is the only user of
libiscsi in debian, and since current version of qemu in debian testing
builds with thie libiscsi-dev, the bug went unnoticed.  I'll update the
libiscsi package in a moment, to include the .pc file.  I haven't read
whole thread yet, but I assume that new (2.1-tobe) qemu needs a .pc
file for libiscsi.

More recent libiscsi will _not_ be available directly in debian stable
(wheezy), but I'll provide one in a form of a backport shortly too,
because of exactly this issue.  I'm not sure yet if I'll provide a
backport of libiscsi before doing qemu-2.1 backport, however.

Thank you for the heads-up!

And no, there is no need to tweak qemu for this, the new version
requiriment is here for a reason.

/mjt

>>> I have a patch which
>>> fixes this, so QEMU for Debian testing could include libiscsi again.
>>>
>>> Is a feature regression like this one acceptable? Do we need additional
>>> testing (maybe run the build bots with --enable-xxx, so builds fail when
>>> xxx no longer works)?
>>
>> As mentioned in the e49ab19fcaa617ad6cdfe1ac401327326b6a2552 commit
>> message, this was intentional.  I was reluctant to do it, but ultimately
>> Peter Lieven convinced me that it isn't just about using fancy new APIs;
>> libiscsi was too buggy to be useful until release 1.8.0 (even 1.9.0
>> requires a patch to avoid segfaults, and many more if you want to run it
>> on ARM).
>>
>> Paolo
>