[Qemu-commits] [qemu/qemu] e7ebf0: hw/scsi/vmw_pvscsi: Remove assertion for kick afte...

[Peter Maydell]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: e7ebf057e6a1ca4f5599caea143daa2135175a87
      
https://github.com/qemu/qemu/commit/e7ebf057e6a1ca4f5599caea143daa2135175a87
  Author: Elazar Leibovich <address@hidden>
  Date:   2020-04-01 (Wed, 01 Apr 2020)

  Changed paths:
    M hw/scsi/vmw_pvscsi.c

  Log Message:
  -----------
  hw/scsi/vmw_pvscsi: Remove assertion for kick after reset

When running Ubuntu 3.13.0-65-generic guest, QEMU sometimes crashes
during guest ACPI reset. It crashes on assert(s->rings_info_valid)
in pvscsi_process_io().

Analyzing the crash revealed that it happens when userspace issues
a sync during a reboot syscall.

Below are backtraces we gathered from the guests.

Guest backtrace when issuing PVSCSI_CMD_ADAPTER_RESET:
    pci_device_shutdown
    device_shutdown
    init_pid_ns
    init_pid_ns
    kernel_power_off
    SYSC_reboot

Guest backtrace when issuing PVSCSI_REG_OFFSET_KICK_RW_IO:
    scsi_done
    scsi_dispatch_cmd
    blk_add_timer
    scsi_request_fn
    elv_rb_add
    __blk_run_queue
    queue_unplugged
    blk_flush_plug_list
    blk_finish_plug
    ext4_writepages
    set_next_entity
    do_writepages
    __filemap_fdatawrite_range
    filemap_write_and_wait_range
    ext4_sync_file
    ext4_sync_file
    do_fsync
    sys_fsync

Since QEMU pvscsi should imitate VMware pvscsi device emulation,
we decided to imitate VMware's behavior in this case.

To check VMware behavior, we wrote a kernel module that issues
a reset to the pvscsi device and then issues a kick. We ran it on
VMware ESXi 6.5 and it seems that it simply ignores the kick.
Hence, we decided to ignore the kick as well.

Signed-off-by: Elazar Leibovich <address@hidden>
Signed-off-by: Liran Alon <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: b822dfaecd89aa4f2036be9f3c098ec5ab1d27d6
      
https://github.com/qemu/qemu/commit/b822dfaecd89aa4f2036be9f3c098ec5ab1d27d6
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2020-04-01 (Wed, 01 Apr 2020)

  Changed paths:
    M hw/isa/isa-superio.c
    M hw/isa/smc37c669-superio.c
    M include/hw/isa/superio.h

  Log Message:
  -----------
  hw/isa/superio: Correct the license text

The license is the 'GNU General Public License v2.0 or later',
not 'and':

  This program is free software; you can redistribute it and/ori
  modify it under the terms of the GNU General Public License as
  published by the Free Software Foundation; either version 2 of
  the License, or (at your option) any later version.

Fix the license comment.

Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 3b703feaf8a27451d756b5db6aeaa8276928b595
      
https://github.com/qemu/qemu/commit/3b703feaf8a27451d756b5db6aeaa8276928b595
  Author: Paolo Bonzini <address@hidden>
  Date:   2020-04-01 (Wed, 01 Apr 2020)

  Changed paths:
    M hw/virtio/Kconfig

  Log Message:
  -----------
  virtio-iommu: depend on PCI

The virtio-iommu device attaches itself to a PCI bus, so it makes
no sense to include it unless PCI is supported---and in fact
compilation fails without this change.

Reported-by: Gerd Hoffmann <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 4951247d8be253075e6e85104301a61525318d54
      
https://github.com/qemu/qemu/commit/4951247d8be253075e6e85104301a61525318d54
  Author: Marc-André Lureau <address@hidden>
  Date:   2020-04-01 (Wed, 01 Apr 2020)

  Changed paths:
    M softmmu/vl.c

  Log Message:
  -----------
  softmmu: fix crash with invalid -M memory-backend=

Fixes: fe64d06afc1c5d895f220c268cfe4d5f1e65d44e ("vl.c: ensure that
ram_size matches size of machine.memory-backend")
Signed-off-by: Marc-André Lureau <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 674fc21ff6200148675d8f13c192a4cf94d187c2
      
https://github.com/qemu/qemu/commit/674fc21ff6200148675d8f13c192a4cf94d187c2
  Author: Roman Bolshakov <address@hidden>
  Date:   2020-04-01 (Wed, 01 Apr 2020)

  Changed paths:
    M MAINTAINERS

  Log Message:
  -----------
  MAINTAINERS: Add an entry for the HVF accelerator

Cc: Nikita Leshenko <address@hidden>
Cc: Sergio Andres Gomez Del Real <address@hidden>
Cc: Patrick Colp <address@hidden>
Cc: Cameron Esfahani <address@hidden>
Cc: Liran Alon <address@hidden>
Cc: Heiher <address@hidden>

Signed-off-by: Roman Bolshakov <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: b87c99d0731fa30f1f455b211cbcf385b0fe427c
      
https://github.com/qemu/qemu/commit/b87c99d0731fa30f1f455b211cbcf385b0fe427c
  Author: Robert Hoo <address@hidden>
  Date:   2020-04-01 (Wed, 01 Apr 2020)

  Changed paths:
    M util/bufferiszero.c

  Log Message:
  -----------
  util/bufferiszero: assign length_to_accel value for each accelerator case

Because in unit test, init_accel() will be called several times, each with
different accelerator type.

Signed-off-by: Robert Hoo <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 8f13a39dc02ea8a3e923102a8444185630c635ea
      
https://github.com/qemu/qemu/commit/8f13a39dc02ea8a3e923102a8444185630c635ea
  Author: Robert Hoo <address@hidden>
  Date:   2020-04-01 (Wed, 01 Apr 2020)

  Changed paths:
    M util/bufferiszero.c

  Log Message:
  -----------
  util/bufferiszero: improve avx2 accelerator

By increasing avx2 length_to_accel to 128, we can simplify its logic and reduce 
a
branch.

The authorship of this patch actually belongs to Richard Henderson
<address@hidden>, I just fixed a boundary case on his
original patch.

Suggested-by: Richard Henderson <address@hidden>
Signed-off-by: Robert Hoo <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 622e99c5cfcb43d89dc39ed780ab43f48bf748c6
      
https://github.com/qemu/qemu/commit/622e99c5cfcb43d89dc39ed780ab43f48bf748c6
  Author: Igor Mammedov <address@hidden>
  Date:   2020-04-02 (Thu, 02 Apr 2020)

  Changed paths:
    M softmmu/vl.c

  Log Message:
  -----------
  vl: fix broken IPA range for ARM -M virt with KVM enabled

Commit a1b18df9a4848, broke virt_kvm_type() logic, which depends on
maxram_size, ram_size, ram_slots being parsed/set on machine instance
at the time accelerator (KVM) is initialized.

set_memory_options() part was already reverted by commit 2a7b18a3205b,
so revert remaining initialization of above machine fields to make
virt_kvm_type() work as it used to.

Signed-off-by: Igor Mammedov <address@hidden>
Reported-by: Auger Eric <address@hidden>
Reviewed-by: Eric Auger <address@hidden>
Tested-by: Eric Auger <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: ddd31732a7379e056749836ff37ff57718083ddb
      
https://github.com/qemu/qemu/commit/ddd31732a7379e056749836ff37ff57718083ddb
  Author: Roman Bolshakov <address@hidden>
  Date:   2020-04-02 (Thu, 02 Apr 2020)

  Changed paths:
    M target/i386/hvf/vmx.h

  Log Message:
  -----------
  i386: hvf: Reset IRQ inhibition after moving RIP

The sequence of instructions exposes an issue:
  sti
  hlt

Interrupts cannot be delivered to hvf after hlt instruction cpu because
HF_INHIBIT_IRQ_MASK is set just before hlt is handled and never reset
after moving instruction pointer beyond hlt.

So, after hvf_vcpu_exec() returns, CPU thread gets locked up forever in
qemu_wait_io_event() (cpu_thread_is_idle() evaluates inhibition
flag and considers the CPU idle if the flag is set).

Cc: Cameron Esfahani <address@hidden>
Signed-off-by: Roman Bolshakov <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: f602d047ac21fc10bc325bf12fe61f4f5c4360d4
      
https://github.com/qemu/qemu/commit/f602d047ac21fc10bc325bf12fe61f4f5c4360d4
  Author: Dr. David Alan Gilbert <address@hidden>
  Date:   2020-04-02 (Thu, 02 Apr 2020)

  Changed paths:
    M hw/char/serial.c

  Log Message:
  -----------
  serial: Fix double migration data

After c9808d60281 we have both an object representing the serial-isa
device and a separate object representing the underlying common serial
uart.  Both of these have vmsd's associated with them and thus the
migration stream ends up with two copies of the migration data - the
serial-isa includes the vmstate of the core serial.   Besides
being wrong, it breaks backwards migration compatibility.

Fix this by removing the dc->vmsd from the core device, so it only
gets migrated by any parent devices including it.
Add a vmstate_serial_mm so that any device that uses serial_mm_init
rather than creating a device still gets migrated.
(That doesn't fix backwards migration for serial_mm_init users,
but does seem to work forwards for ppce500).

Fixes: c9808d60281 ('serial: realize the serial device')
Buglink: https://bugs.launchpad.net/qemu/+bug/1869426
Signed-off-by: Dr. David Alan Gilbert <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 4a910e1f6ab4155ec8b24c49b2585cc486916985
      
https://github.com/qemu/qemu/commit/4a910e1f6ab4155ec8b24c49b2585cc486916985
  Author: Vitaly Kuznetsov <address@hidden>
  Date:   2020-04-02 (Thu, 02 Apr 2020)

  Changed paths:
    M target/i386/kvm.c

  Log Message:
  -----------
  target/i386: do not set unsupported VMX secondary execution controls

Commit 048c95163b4 ("target/i386: work around KVM_GET_MSRS bug for
secondary execution controls") added a workaround for KVM pre-dating
commit 6defc591846d ("KVM: nVMX: include conditional controls in /dev/kvm
KVM_GET_MSRS") which wasn't setting certain available controls. The
workaround uses generic CPUID feature bits to set missing VMX controls.

It was found that in some cases it is possible to observe hosts which
have certain CPUID features but lack the corresponding VMX control.

In particular, it was reported that Azure VMs have RDSEED but lack
VMX_SECONDARY_EXEC_RDSEED_EXITING; attempts to enable this feature
bit result in QEMU abort.

Resolve the issue but not applying the workaround when we don't have
to. As there is no good way to find out if KVM has the fix itself, use
95c5c7c77c ("KVM: nVMX: list VMX MSRs in KVM_GET_MSR_INDEX_LIST") instead
as these [are supposed to] come together.

Fixes: 048c95163b4 ("target/i386: work around KVM_GET_MSRS bug for secondary 
execution controls")
Suggested-by: Paolo Bonzini <address@hidden>
Signed-off-by: Vitaly Kuznetsov <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 9cbc36497c9c0ab92008f3dc71748640035be3af
      
https://github.com/qemu/qemu/commit/9cbc36497c9c0ab92008f3dc71748640035be3af
  Author: Marc-André Lureau <address@hidden>
  Date:   2020-04-02 (Thu, 02 Apr 2020)

  Changed paths:
    M migration/migration.c

  Log Message:
  -----------
  migration: fix cleanup_bh leak on resume

Since commit 8c6b0356b53977bcfdea5299db07884915425b0c ("util/async:
make bh_aio_poll() O(1)"), migration-test reveals a leak:

QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64
tests/qtest/migration-test  -p /x86_64/migration/postcopy/recovery
tests/qtest/libqtest.c:140: kill_qemu() tried to terminate QEMU
process but encountered exit status 1 (expected 0)

=================================================================
==2082571==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x7f25971dfc58 in __interceptor_malloc (/lib64/libasan.so.5+0x10dc58)
    #1 0x7f2596d08358 in g_malloc (/lib64/libglib-2.0.so.0+0x57358)
    #2 0x560970d006f8 in qemu_bh_new /home/elmarco/src/qemu/util/main-loop.c:532
    #3 0x5609704afa02 in migrate_fd_connect
/home/elmarco/src/qemu/migration/migration.c:3407
    #4 0x5609704b6b6f in migration_channel_connect
/home/elmarco/src/qemu/migration/channel.c:92
    #5 0x5609704b2bfb in socket_outgoing_migration
/home/elmarco/src/qemu/migration/socket.c:108
    #6 0x560970b9bd6c in qio_task_complete /home/elmarco/src/qemu/io/task.c:196
    #7 0x560970b9aa97 in qio_task_thread_result
/home/elmarco/src/qemu/io/task.c:111
    #8 0x7f2596cfee3a  (/lib64/libglib-2.0.so.0+0x4de3a)

Signed-off-by: Marc-André Lureau <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Juan Quintela <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: b3fbb328123575e5b39e35e13ecbd4927569a82b
      
https://github.com/qemu/qemu/commit/b3fbb328123575e5b39e35e13ecbd4927569a82b
  Author: Marc-André Lureau <address@hidden>
  Date:   2020-04-02 (Thu, 02 Apr 2020)

  Changed paths:
    M qapi/qmp-dispatch.c

  Log Message:
  -----------
  qmp: fix leak on callbacks that return both value and error

Direct leak of 4120 byte(s) in 1 object(s) allocated from:
    #0 0x7fa114931887 in __interceptor_calloc (/lib64/libasan.so.6+0xb0887)
    #1 0x7fa1144ad8f0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x588f0)
    #2 0x561e3c9c8897 in qmp_object_add 
/home/elmarco/src/qemu/qom/qom-qmp-cmds.c:291
    #3 0x561e3cf48736 in qmp_dispatch 
/home/elmarco/src/qemu/qapi/qmp-dispatch.c:155
    #4 0x561e3c8efb36 in monitor_qmp_dispatch 
/home/elmarco/src/qemu/monitor/qmp.c:145
    #5 0x561e3c8f09ed in monitor_qmp_bh_dispatcher 
/home/elmarco/src/qemu/monitor/qmp.c:234
    #6 0x561e3d08c993 in aio_bh_call /home/elmarco/src/qemu/util/async.c:136
    #7 0x561e3d08d0a5 in aio_bh_poll /home/elmarco/src/qemu/util/async.c:164
    #8 0x561e3d0a535a in aio_dispatch 
/home/elmarco/src/qemu/util/aio-posix.c:380
    #9 0x561e3d08e3ca in aio_ctx_dispatch 
/home/elmarco/src/qemu/util/async.c:298
    #10 0x7fa1144a776e in g_main_context_dispatch 
(/lib64/libglib-2.0.so.0+0x5276e)

Signed-off-by: Marc-André Lureau <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Markus Armbruster <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 7f5d9b206d1e86425faa5b84b551068bf044b823
      
https://github.com/qemu/qemu/commit/7f5d9b206d1e86425faa5b84b551068bf044b823
  Author: Paolo Bonzini <address@hidden>
  Date:   2020-04-02 (Thu, 02 Apr 2020)

  Changed paths:
    M qom/qom-qmp-cmds.c

  Log Message:
  -----------
  object-add: don't create return value if failed

No need to return an empty value from object-add (it would also leak
if the command failed).  While at it, remove the "if" around object_unref
since object_unref handles NULL arguments just fine.

Reported-by: Marc-André Lureau <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 0dc0389fa5455bb264866701892ed06bc3eb06e4
      
https://github.com/qemu/qemu/commit/0dc0389fa5455bb264866701892ed06bc3eb06e4
  Author: Igor Mammedov <address@hidden>
  Date:   2020-04-02 (Thu, 02 Apr 2020)

  Changed paths:
    M hw/xen/xen-common.c

  Log Message:
  -----------
  xen: fixup RAM memory region initialization

Since bd457782b3b0 ("x86/pc: use memdev for RAM") Xen
machine fails to start with:
   qemu-system-i386: xen: failed to populate ram at 0

The reason is that xen_ram_alloc() which is called by
memory_region_init_ram(), compares memory region with
statically allocated 'global' ram_memory memory region
that it uses for RAM, and does nothing in case it matches.

While it's possible feed machine->ram to xen_ram_alloc()
in the same manner to keep that hack working, I'd prefer
not to keep that circular dependency and try to untangle that.

However it doesn't look trivial to fix, so as temporary
fixup opt out Xen machine from memdev based RAM allocation,
and let xen_ram_alloc() do its trick for now.

Reported-by: Anthony PERARD <address@hidden>
Signed-off-by: Igor Mammedov <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 5142ca078d1cbc0f77b0f385d28cdb3e504e62bd
      
https://github.com/qemu/qemu/commit/5142ca078d1cbc0f77b0f385d28cdb3e504e62bd
  Author: Peter Maydell <address@hidden>
  Date:   2020-04-02 (Thu, 02 Apr 2020)

  Changed paths:
    M MAINTAINERS
    M hw/char/serial.c
    M hw/isa/isa-superio.c
    M hw/isa/smc37c669-superio.c
    M hw/scsi/vmw_pvscsi.c
    M hw/virtio/Kconfig
    M hw/xen/xen-common.c
    M include/hw/isa/superio.h
    M migration/migration.c
    M qapi/qmp-dispatch.c
    M qom/qom-qmp-cmds.c
    M softmmu/vl.c
    M target/i386/hvf/vmx.h
    M target/i386/kvm.c
    M util/bufferiszero.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging

Bugfixes for 5.0-rc2.

# gpg: Signature made Thu 02 Apr 2020 19:57:47 BST
# gpg:                using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg:                issuer "address@hidden"
# gpg: Good signature from "Paolo Bonzini <address@hidden>" [full]
# gpg:                 aka "Paolo Bonzini <address@hidden>" [full]
# Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
#      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83

* remotes/bonzini/tags/for-upstream:
  xen: fixup RAM memory region initialization
  object-add: don't create return value if failed
  qmp: fix leak on callbacks that return both value and error
  migration: fix cleanup_bh leak on resume
  target/i386: do not set unsupported VMX secondary execution controls
  serial: Fix double migration data
  i386: hvf: Reset IRQ inhibition after moving RIP
  vl: fix broken IPA range for ARM -M virt with KVM enabled
  util/bufferiszero: improve avx2 accelerator
  util/bufferiszero: assign length_to_accel value for each accelerator case
  MAINTAINERS: Add an entry for the HVF accelerator
  softmmu: fix crash with invalid -M memory-backend=
  virtio-iommu: depend on PCI
  hw/isa/superio: Correct the license text
  hw/scsi/vmw_pvscsi: Remove assertion for kick after reset

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/2833ad487cff...5142ca078d1c