1. 07 2月, 2018 12 次提交
    • P
    • L
      ivshmem: Disable irqfd on device reset · a4022791
      Ladi Prosek 提交于
      The effects of ivshmem_enable_irqfd() was not undone on device reset.
      
      This manifested as:
      ivshmem_add_kvm_msi_virq: Assertion `!s->msi_vectors[vector].pdev' failed.
      
      when irqfd was enabled before reset and then enabled again after reset, making
      ivshmem_enable_irqfd() run for the second time.
      
      To reproduce, run:
      
        ivshmem-server
      
      and QEMU with:
      
        -device ivshmem-doorbell,chardev=iv
        -chardev socket,path=/tmp/ivshmem_socket,id=iv
      
      then install the Windows driver, at the time of writing available at:
      
      https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/ivshmem
      
      and crash-reboot the guest by inducing a BSOD.
      Signed-off-by: NLadi Prosek <lprosek@redhat.com>
      Message-Id: <20171211072110.9058-5-lprosek@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      a4022791
    • L
      ivshmem: Improve MSI irqfd error handling · 0b88dd94
      Ladi Prosek 提交于
      Adds a rollback path to ivshmem_enable_irqfd() and fixes
      ivshmem_disable_irqfd() to bail if irqfd has not been enabled.
      
      To reproduce, run:
      
        ivshmem-server -n 0
      
      and QEMU with:
      
        -device ivshmem-doorbell,chardev=iv
        -chardev socket,path=/tmp/ivshmem_socket,id=iv
      
      then load, unload, and load again the Windows driver, at the time of writing
      available at:
      
      https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/ivshmem
      
      The issue is believed to have been masked by other guest drivers, notably
      Linux ones, not enabling MSI-X on the device.
      Signed-off-by: NLadi Prosek <lprosek@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20171211072110.9058-4-lprosek@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      0b88dd94
    • L
      ivshmem: Always remove irqfd notifiers · 089fd803
      Ladi Prosek 提交于
      As of commit 660c97ee ("ivshmem: use kvm irqfd for msi notifications"),
      QEMU crashes with:
      
      ivshmem: msix_set_vector_notifiers failed
      msix_unset_vector_notifiers: Assertion `dev->msix_vector_use_notifier && dev->msix_vector_release_notifier' failed.
      
      if MSI-X is repeatedly enabled and disabled on the ivshmem device, for example
      by loading and unloading the Windows ivshmem driver. This is because
      msix_unset_vector_notifiers() doesn't call any of the release notifier callbacks
      since MSI-X is already disabled at that point (msix_enabled() returning false
      is how this transition is detected in the first place). Thus ivshmem_vector_mask()
      doesn't run and when MSI-X is subsequently enabled again ivshmem_vector_unmask()
      fails.
      
      This is fixed by keeping track of unmasked vectors and making sure that
      ivshmem_vector_mask() always runs on MSI-X disable.
      
      Fixes: 660c97ee ("ivshmem: use kvm irqfd for msi notifications")
      Signed-off-by: NLadi Prosek <lprosek@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20171211072110.9058-3-lprosek@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      089fd803
    • L
      ivshmem: Don't update non-existent MSI routes · e6a354be
      Ladi Prosek 提交于
      As of commit 660c97ee ("ivshmem: use kvm irqfd for msi notifications"),
      QEMU crashes with:
      
        kvm_irqchip_commit_routes: Assertion `ret == 0' failed.
      
      if the ivshmem device is configured with more vectors than what the server
      supports. This is caused by the ivshmem_vector_unmask() being called on
      vectors that have not been initialized by ivshmem_add_kvm_msi_virq().
      
      This commit fixes it by adding a simple check to the mask and unmask
      callbacks.
      
      Note that the opposite mismatch, if the server supplies more vectors than
      what the device is configured for, is already handled and leads to output
      like:
      
        Too many eventfd received, device has 1 vectors
      
      To reproduce the assert, run:
      
        ivshmem-server -n 0
      
      and QEMU with:
      
        -device ivshmem-doorbell,chardev=iv
        -chardev socket,path=/tmp/ivshmem_socket,id=iv
      
      then load the Windows driver, at the time of writing available at:
      
      https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/ivshmem
      
      The issue is believed to have been masked by other guest drivers, notably
      Linux ones, not enabling MSI-X on the device.
      
      Fixes: 660c97ee ("ivshmem: use kvm irqfd for msi notifications")
      Signed-off-by: NLadi Prosek <lprosek@redhat.com>
      Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20171211072110.9058-2-lprosek@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      e6a354be
    • K
      chardev/char-socket: add POLLHUP handler · a8aa6197
      Klim Kireev 提交于
      The following behavior was observed for QEMU configured by libvirt
      to use guest agent as usual for the guests without virtio-serial
      driver (Windows or the guest remaining in BIOS stage).
      
      In QEMU on first connect to listen character device socket
      the listen socket is removed from poll just after the accept().
      virtio_serial_guest_ready() returns 0 and the descriptor
      of the connected Unix socket is removed from poll and it will
      not be present in poll() until the guest will initialize the driver
      and change the state of the serial to "guest connected".
      
      In libvirt connect() to guest agent is performed on restart and
      is run under VM state lock. Connect() is blocking and can
      wait forever.
      In this case libvirt can not perform ANY operation on that VM.
      
      The bug can be easily reproduced this way:
      
      Terminal 1:
      qemu-system-x86_64 -m 512 -device pci-serial,chardev=serial1 -chardev socket,id=serial1,path=/tmp/console.sock,server,nowait
      (virtio-serial and isa-serial also fit)
      
      Terminal 2:
      minicom -D unix\#/tmp/console.sock
      (type something and press enter)
      C-a x (to exit)
      
      Do 3 times:
      minicom -D unix\#/tmp/console.sock
      C-a x
      
      It needs 4 connections, because the first one is accepted by QEMU, then two are queued by
      the kernel, and the 4th blocks.
      
      The problem is that QEMU doesn't add a read watcher after succesful read
      until the guest device wants to acquire recieved data, so
      I propose to install a separate pullhup watcher regardless of
      whether the device waits for data or not.
      Signed-off-by: NKlim Kireev <klim.kireev@virtuozzo.com>
      Message-Id: <20180125135129.9305-1-klim.kireev@virtuozzo.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      a8aa6197
    • P
      memory: do explicit cleanup when remove listeners · d25836ca
      Peter Xu 提交于
      When unregister memory listeners, we should call, e.g.,
      region_del() (and possibly other undo operations) on every existing
      memory region sections there, otherwise we may leak resources that are
      held during the region_add(). This patch undo the stuff for the
      listeners, which emulates the case when the address space is set from
      current to an empty state.
      
      I found this problem when debugging a refcount leak issue that leads to
      a device unplug event lost (please see the "Bug:" line below).  In that
      case, the leakage of resource is the PCI BAR memory region refcount.
      And since memory regions are not keeping their own refcount but onto
      their owners, so the vfio-pci device's (who is the owner of the PCI BAR
      memory regions) refcount is leaked, and event missing.
      
      We had encountered similar issues before and fixed in other
      way (ee4c1128, "vhost: Release memory references on cleanup"). This
      patch can be seen as a more high-level fix of similar problems that are
      caused by the resource leaks from memory listeners. So now we can remove
      the explicit unref of memory regions since that'll be done altogether
      during unregistering of listeners now.
      
      Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1531393Signed-off-by: NPeter Xu <peterx@redhat.com>
      Message-Id: <20180122060244.29368-5-peterx@redhat.com>
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      d25836ca
    • P
      vfio: listener unregister before unset container · 36968626
      Peter Xu 提交于
      After next patch, listener unregister will need the container to be
      alive.  Let's move this unregister phase to be before unset container,
      since that operation will free the backend container in kernel,
      otherwise we'll get these after next patch:
      
      qemu-system-x86_64: VFIO_UNMAP_DMA: -22
      qemu-system-x86_64: vfio_dma_unmap(0x559bf53a4590, 0x0, 0xa0000) = -22 (Invalid argument)
      Signed-off-by: NPeter Xu <peterx@redhat.com>
      Message-Id: <20180122060244.29368-4-peterx@redhat.com>
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Acked-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      36968626
    • P
      arm: postpone device listener unregister · 0bbe4354
      Peter Xu 提交于
      It's a preparation for follow-up patch to call region_del() in
      memory_listener_unregister(), otherwise all device addr attached with
      kvm_devices_head will be reset before calling kvm_arm_set_device_addr.
      Signed-off-by: NPeter Xu <peterx@redhat.com>
      Message-Id: <20180122060244.29368-3-peterx@redhat.com>
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      0bbe4354
    • P
      vhost: add traces for memory listeners · 0750b060
      Peter Xu 提交于
      Trace these operations on two memory listeners.  It helps to verify the
      new memory listener fix, and good to keep them there.
      Signed-off-by: NPeter Xu <peterx@redhat.com>
      Message-Id: <20180122060244.29368-2-peterx@redhat.com>
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      0750b060
    • M
      ucontext: annotate coroutine stack for ASAN · d83414e1
      Marc-André Lureau 提交于
      It helps ASAN to detect more leaks on coroutine stacks, and to get rid
      of some extra warnings.
      
      Before:
      
      tests/test-coroutine -p
      /basic/lifecycle
      /basic/lifecycle: ==20781==WARNING: ASan doesn't fully support
      makecontext/swapcontext functions and may produce false positives in
      some cases!
      ==20781==WARNING: ASan is ignoring requested __asan_handle_no_return:
      stack top: 0x7ffcb184d000; bottom 0x7ff6c4cfd000; size: 0x0005ecb50000
      (25446121472)
      False positive error reports may follow
      For details see https://github.com/google/sanitizers/issues/189
      OK
      
      After:
      
      tests/test-coroutine -p /basic/lifecycle
      /basic/lifecycle: ==21110==WARNING: ASan doesn't fully support
      makecontext/swapcontext functions and may produce false positives in
      some cases!
      OK
      
      A similar work would need to be done for sigaltstack & windows fibers
      to have similar coverage. Since ucontext is preferred, I didn't bother
      checking the other coroutine implementations for now.
      
      Update travis to fix the build with ASAN annotations.
      Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Message-Id: <20180116151152.4040-4-marcandre.lureau@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      d83414e1
    • M
      build-sys: add --enable-sanitizers · 247724cb
      Marc-André Lureau 提交于
      Typical slowdown introduced by AddressSanitizer is 2x.
      UBSan shouldn't have much impact on runtime cost.
      
      Enable it by default when --enable-debug, unless --disable-sanitizers.
      Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Message-Id: <20180116151152.4040-3-marcandre.lureau@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      247724cb
  2. 06 2月, 2018 7 次提交
  3. 05 2月, 2018 11 次提交
  4. 03 2月, 2018 3 次提交
    • P
      Merge remote-tracking branch 'remotes/kraxel/tags/ui-20180202-pull-request' into staging · f24ee107
      Peter Maydell 提交于
      ui: use QIONetListener in vnc, bugfixes for sdl1 and vnc.
      
      # gpg: Signature made Fri 02 Feb 2018 07:17:36 GMT
      # gpg:                using RSA key 4CB6D8EED3E87138
      # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>"
      # gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>"
      # gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>"
      # Primary key fingerprint: A032 8CFF B93A 17A7 9901  FE7D 4CB6 D8EE D3E8 7138
      
      * remotes/kraxel/tags/ui-20180202-pull-request:
        ui: correctly advance output buffer when writing SASL data
        ui: convert VNC server to QIONetListener
        ui: fix mixup between qnum and qcode in SDL1 key handling
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      f24ee107
    • P
      Merge remote-tracking branch 'remotes/kraxel/tags/vga-20180202-pull-request' into staging · fb2516ef
      Peter Maydell 提交于
      virtio-gpu: disallow vIOMMU
      
      # gpg: Signature made Fri 02 Feb 2018 08:31:52 GMT
      # gpg:                using RSA key 4CB6D8EED3E87138
      # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>"
      # gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>"
      # gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>"
      # Primary key fingerprint: A032 8CFF B93A 17A7 9901  FE7D 4CB6 D8EE D3E8 7138
      
      * remotes/kraxel/tags/vga-20180202-pull-request:
        virtio-gpu: disallow vIOMMU
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      fb2516ef
    • P
      Merge remote-tracking branch 'remotes/gkurz/tags/for-upstream' into staging · f74425e2
      Peter Maydell 提交于
      This series is mostly about 9p request cancellation. It fixes a
      long standing bug (read "specification violation") where the server
      would send an invalid response when the client has cancelled an
      in-flight request. This was causing annoying spurious EINTR returns
      in linux. The fix comes with some related testing in QTEST.
      
      Other patches are code cleanup and improvements.
      
      # gpg: Signature made Fri 02 Feb 2018 10:16:03 GMT
      # gpg:                using RSA key 71D4D5E5822F73D6
      # gpg: Good signature from "Greg Kurz <groug@kaod.org>"
      # gpg:                 aka "Gregory Kurz <gregory.kurz@free.fr>"
      # gpg:                 aka "[jpeg image of size 3330]"
      # Primary key fingerprint: B482 8BAF 9431 40CE F2A3  4910 71D4 D5E5 822F 73D6
      
      * remotes/gkurz/tags/for-upstream:
        tests/virtio-9p: explicitly handle potential integer overflows
        tests: virtio-9p: add FLUSH operation test
        libqos/virtio: return length written into used descriptor
        tests: virtio-9p: add WRITE operation test
        tests: virtio-9p: add LOPEN operation test
        tests: virtio-9p: use the synth backend
        tests: virtio-9p: wait for completion in the test code
        tests: virtio-9p: move request tag to the test functions
        9pfs: Correctly handle cancelled requests
        9pfs: drop v9fs_register_transport()
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      f74425e2
  5. 02 2月, 2018 7 次提交