[Qemu-devel] [ANNOUNCE] QEMU 2.12.0-rc4 is now available

[Qemu-devel] [ANNOUNCE] QEMU 2.12.0-rc4 is now available

[Michael Roth]

Hello,

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

  http://download.qemu-project.org/qemu-2.12.0-rc4.tar.xz
  http://download.qemu-project.org/qemu-2.12.0-rc4.tar.xz.sig

A note from the maintainer:

  Barring any reports of showstopper bugs, the plan is to release
  2.12.0 with no further changes on Tuesday 24th April.

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

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

The release plan, as well a documented known issues for release
candidates, are available at:

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

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

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

Changes since rc3:

27e757e29c: Update version for v2.12.0-rc4 release (Peter Maydell)
6f660996f1: Revert "mux: fix ctrl-a b again" (Peter Maydell)
ce8d408205: fpu: Bound increment for scalbn (Richard Henderson)
1b2503fcf7: mux: fix ctrl-a b again (Marc-André Lureau)
bb3ba35f20: linux-user: check that all of AArch64 SVE extended sigframe is writable (Peter Maydell)
9cb4e398c2: fpu/softfloat: check for Inf / x or 0 / x before /0 (Alex Bennée)
0d914f39a7: i386: Don't automatically enable FEAT_KVM_HINTS bits (Eduardo Habkost)
aebbdbee55: vhost: do not verify ring mappings when IOMMU is enabled (Jason Wang)
2a6b5372d7: Makefile: install gtk message catalogs if CONFIG_GTK=y too, not only =m (Michael Tokarev)
25bf2426f3: iotests: fix 169 (Vladimir Sementsov-Ogievskiy)
605bc8be42: qcow2: try load bitmaps only once (Vladimir Sementsov-Ogievskiy)
aac8f55633: linux-user/signal.c: Put AArch64 frame record in the right place (Peter Maydell)
161dfd1e7f: tcg/mips: Handle large offsets from target env to tlb_table (Peter Maydell)
801bc56336: fpu/softfloat: raise float_invalid for NaN/Inf in round_to_int_and_pack (Alex Bennée)
000761dc0c: m68k: fix exception stack frame for 68000 (Pavel Dovgalyuk)
6245327a36: softfloat: fix {min, max}nummag for same-abs-value inputs (Emilio G. Cota)

Re: [Qemu-devel] [ANNOUNCE] QEMU 2.12.0-rc4 is now available

[Laszlo Ersek]

Hi Peter,

On 04/18/18 16:56, Michael Roth wrote:
> A note from the maintainer:
> 
>   Barring any reports of showstopper bugs, the plan is to release
>   2.12.0 with no further changes on Tuesday 24th April.

I just noticed two QAPI bugs introduced in 2.12, in the following two
commits:

(1) ca230ff33f89 ("qmp: add architecture specific cpu data for
query-cpus-fast", 2018-02-26)

This commit added @arch to @CpuInfoFast, but it failed to set the new
field to CPU_INFO_ARCH_OTHER in qmp_query_cpus_fast(), when TARGET_S390X
is not defined.

(2) 25fa194b7b11 ("RISC-V Build Infrastructure", 2018-03-07)

This commit added the @riscv enum constant to @CpuInfoArch (used in both
@CpuInfo and @CpuInfoFast -- the return types of the @query-cpus and
@query-cpus-fast commands, respectively), and assigned, in both return
structures, the @CpuInfoRISCV sub-structure to the new enum value.

However, qmp_query_cpus_fast() does not populate the sub-structure, when
TARGET_RISCV is defined; only qmp_query_cpus() does.

The fixes don't look complicated. Do you want to hold the release while
I post the fixes?

I don't think these bugs are "show stoppers". On the other hand, QAPI is
an external interface.

Thanks
Laszlo

Re: [Qemu-devel] [ANNOUNCE] QEMU 2.12.0-rc4 is now available

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]

On 04/24/2018 07:46 AM, Laszlo Ersek wrote:

> I just noticed two QAPI bugs introduced in 2.12, in the following two
> commits:
> 
> (1) ca230ff33f89 ("qmp: add architecture specific cpu data for
> query-cpus-fast", 2018-02-26)
> 
> This commit added @arch to @CpuInfoFast, but it failed to set the new
> field to CPU_INFO_ARCH_OTHER in qmp_query_cpus_fast(), when TARGET_S390X
> is not defined.

We zero-initialize info->value, and info->value->arch == 0 happens to be
CPU_INFO_ARCH_X86 which is associated with the empty type CpuInfoOther,
which is no different than what we would have had with
CPU_INFO_ARCH_OTHER.  So the drawback is that on x86 architectures,
things look correct; while on sparc, ppc, mips, and tricore (which have
a specific type) and on all other platforms (which should use "other"),
the output wrongly reports "arch":"x86" but does not crash.

> 
> (2) 25fa194b7b11 ("RISC-V Build Infrastructure", 2018-03-07)
> 
> This commit added the @riscv enum constant to @CpuInfoArch (used in both
> @CpuInfo and @CpuInfoFast -- the return types of the @query-cpus and
> @query-cpus-fast commands, respectively), and assigned, in both return
> structures, the @CpuInfoRISCV sub-structure to the new enum value.

Ouch - we SHOULD have used 'CpuInfoOther' rather than 'CpuInfoRISCV' for
@CpuInfoFast.  We do NOT want to report the 'pc' field in the fast query.

> 
> However, qmp_query_cpus_fast() does not populate the sub-structure, when
> TARGET_RISCV is defined; only qmp_query_cpus() does.

Indeed, the output wrongly reports "arch":"x86" instead of
"arch":"riscv" - but at least things do not crash.

> 
> The fixes don't look complicated. Do you want to hold the release while
> I post the fixes?
> 
> I don't think these bugs are "show stoppers". On the other hand, QAPI is
> an external interface.

It's too late for the 2.12 release.  We'll definitely fix things in
2.12.1 (so cc the patches to qemu-stable), and should document in the
release notes that query-cpus-fast is known to report bogus "arch" data
for all architectures except x86 and s390, so applications should be
careful to not rely on the bogus information.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: [Qemu-devel] [ANNOUNCE] QEMU 2.12.0-rc4 is now available

[Laszlo Ersek]

On 04/24/18 15:39, Eric Blake wrote:
> On 04/24/2018 07:46 AM, Laszlo Ersek wrote:
> 
>> I just noticed two QAPI bugs introduced in 2.12, in the following two
>> commits:
>>
>> (1) ca230ff33f89 ("qmp: add architecture specific cpu data for
>> query-cpus-fast", 2018-02-26)
>>
>> This commit added @arch to @CpuInfoFast, but it failed to set the new
>> field to CPU_INFO_ARCH_OTHER in qmp_query_cpus_fast(), when TARGET_S390X
>> is not defined.
> 
> We zero-initialize info->value, and info->value->arch == 0 happens to be
> CPU_INFO_ARCH_X86 which is associated with the empty type CpuInfoOther,
> which is no different than what we would have had with
> CPU_INFO_ARCH_OTHER.  So the drawback is that on x86 architectures,
> things look correct; while on sparc, ppc, mips, and tricore (which have
> a specific type) and on all other platforms (which should use "other"),
> the output wrongly reports "arch":"x86" but does not crash.

I agree.

> 
>>
>> (2) 25fa194b7b11 ("RISC-V Build Infrastructure", 2018-03-07)
>>
>> This commit added the @riscv enum constant to @CpuInfoArch (used in both
>> @CpuInfo and @CpuInfoFast -- the return types of the @query-cpus and
>> @query-cpus-fast commands, respectively), and assigned, in both return
>> structures, the @CpuInfoRISCV sub-structure to the new enum value.
> 
> Ouch - we SHOULD have used 'CpuInfoOther' rather than 'CpuInfoRISCV' for
> @CpuInfoFast.  We do NOT want to report the 'pc' field in the fast query.

Right.

>>
>> However, qmp_query_cpus_fast() does not populate the sub-structure, when
>> TARGET_RISCV is defined; only qmp_query_cpus() does.
> 
> Indeed, the output wrongly reports "arch":"x86" instead of
> "arch":"riscv" - but at least things do not crash.
> 
>>
>> The fixes don't look complicated. Do you want to hold the release while
>> I post the fixes?
>>
>> I don't think these bugs are "show stoppers". On the other hand, QAPI is
>> an external interface.
> 
> It's too late for the 2.12 release.  We'll definitely fix things in
> 2.12.1 (so cc the patches to qemu-stable),

OK, will do.

> and should document in the
> release notes that query-cpus-fast is known to report bogus "arch" data
> for all architectures except x86 and s390, so applications should be
> careful to not rely on the bogus information.

<https://wiki.qemu.org/ChangeLog/2.12#Known_issues> refers to
<https://wiki.qemu.org/Planning/2.12>, so I've added the above sentence
to <https://wiki.qemu.org/Planning/2.12#Issues_that_will_not_be_fixed>.

Thanks, Eric!
Laszlo

Re: [Qemu-devel] [ANNOUNCE] QEMU 2.12.0-rc4 is now available

[Cornelia Huck]

On Tue, 24 Apr 2018 15:56:14 +0200
Laszlo Ersek <lersek@redhat.com> wrote:

> On 04/24/18 15:39, Eric Blake wrote:
> > On 04/24/2018 07:46 AM, Laszlo Ersek wrote:
> >   
> >> I just noticed two QAPI bugs introduced in 2.12, in the following two
> >> commits:
> >>
> >> (1) ca230ff33f89 ("qmp: add architecture specific cpu data for
> >> query-cpus-fast", 2018-02-26)
> >>
> >> This commit added @arch to @CpuInfoFast, but it failed to set the new
> >> field to CPU_INFO_ARCH_OTHER in qmp_query_cpus_fast(), when TARGET_S390X
> >> is not defined.  
> > 
> > We zero-initialize info->value, and info->value->arch == 0 happens to be
> > CPU_INFO_ARCH_X86 which is associated with the empty type CpuInfoOther,
> > which is no different than what we would have had with
> > CPU_INFO_ARCH_OTHER.  So the drawback is that on x86 architectures,
> > things look correct; while on sparc, ppc, mips, and tricore (which have
> > a specific type) and on all other platforms (which should use "other"),
> > the output wrongly reports "arch":"x86" but does not crash.  
> 
> I agree.

As an exercise for the reader: Figure out on which architectures I
tried this out... (Hint: one starts with s and ends with x, while the
other one starts with x.)

> 
> >   
> >>
> >> (2) 25fa194b7b11 ("RISC-V Build Infrastructure", 2018-03-07)
> >>
> >> This commit added the @riscv enum constant to @CpuInfoArch (used in both
> >> @CpuInfo and @CpuInfoFast -- the return types of the @query-cpus and
> >> @query-cpus-fast commands, respectively), and assigned, in both return
> >> structures, the @CpuInfoRISCV sub-structure to the new enum value.  
> > 
> > Ouch - we SHOULD have used 'CpuInfoOther' rather than 'CpuInfoRISCV' for
> > @CpuInfoFast.  We do NOT want to report the 'pc' field in the fast query.  
> 
> Right.
> 
> >>
> >> However, qmp_query_cpus_fast() does not populate the sub-structure, when
> >> TARGET_RISCV is defined; only qmp_query_cpus() does.  
> > 
> > Indeed, the output wrongly reports "arch":"x86" instead of
> > "arch":"riscv" - but at least things do not crash.
> >   
> >>
> >> The fixes don't look complicated. Do you want to hold the release while
> >> I post the fixes?
> >>
> >> I don't think these bugs are "show stoppers". On the other hand, QAPI is
> >> an external interface.  
> > 
> > It's too late for the 2.12 release.  We'll definitely fix things in
> > 2.12.1 (so cc the patches to qemu-stable),  
> 
> OK, will do.
> 
> > and should document in the
> > release notes that query-cpus-fast is known to report bogus "arch" data
> > for all architectures except x86 and s390, so applications should be
> > careful to not rely on the bogus information.  
> 
> <https://wiki.qemu.org/ChangeLog/2.12#Known_issues> refers to
> <https://wiki.qemu.org/Planning/2.12>, so I've added the above sentence
> to <https://wiki.qemu.org/Planning/2.12#Issues_that_will_not_be_fixed>.

The wiki updates look good to me.