Skip to content
Snippets Groups Projects
  1. Mar 03, 2023
    • Jason Wang's avatar
      smmu: switch to use memory_region_unmap_iommu_notifier_range() · 98332f64
      Jason Wang authored
      
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Message-Id: <20230223065924.42503-5-jasowang@redhat.com>
      Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      98332f64
    • Jason Wang's avatar
      memory: introduce memory_region_unmap_iommu_notifier_range() · 7caebbf9
      Jason Wang authored
      
      This patch introduces a new helper to unmap the range of a specific
      IOMMU notifier.
      
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Message-Id: <20230223065924.42503-4-jasowang@redhat.com>
      Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      7caebbf9
    • Jason Wang's avatar
      intel-iommu: fail DEVIOTLB_UNMAP without dt mode · 09adb0e0
      Jason Wang authored
      
      Without dt mode, device IOTLB notifier won't work since guest won't
      send device IOTLB invalidation descriptor in this case. Let's fail
      early instead of misbehaving silently.
      
      Reviewed-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Tested-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Tested-by: default avatarViktor Prutyanov <viktor@daynix.com>
      Buglink: https://bugzilla.redhat.com/2156876
      
      
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Message-Id: <20230223065924.42503-3-jasowang@redhat.com>
      Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      09adb0e0
    • Jason Wang's avatar
      intel-iommu: fail MAP notifier without caching mode · b8d78277
      Jason Wang authored
      
      Without caching mode, MAP notifier won't work correctly since guest
      won't send IOTLB update event when it establishes new mappings in the
      I/O page tables. Let's fail the IOMMU notifiers early instead of
      misbehaving silently.
      
      Reviewed-by: default avatarEric Auger <eric.auger@redhat.com>
      Tested-by: default avatarViktor Prutyanov <viktor@daynix.com>
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Message-Id: <20230223065924.42503-2-jasowang@redhat.com>
      Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      b8d78277
    • Zhenzhong Duan's avatar
      memory: Optimize replay of guest mapping · 6da24341
      Zhenzhong Duan authored
      
      On x86, there are two notifiers registered due to vtd-ir memory region
      splitting the whole address space. During replay of the address space
      for each notifier, the whole address space is scanned which is
      unnecessory.
      
      We only need to scan the space belong to notifier montiored space.
      
      Assert when notifier is used to monitor beyond iommu memory region's
      address space.
      
      Signed-off-by: default avatarZhenzhong Duan <zhenzhong.duan@intel.com>
      Message-Id: <20230215065238.713041-1-zhenzhong.duan@intel.com>
      Acked-by: default avatarPeter Xu <peterx@redhat.com>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      6da24341
    • Yajun Wu's avatar
      chardev/char-socket: set s->listener = NULL in char_socket_finalize · b8a7f51f
      Yajun Wu authored
      
      After live migration with virtio block device, qemu crash at:
      
      	#0  0x000055914f46f795 in object_dynamic_cast_assert (obj=0x559151b7b090, typename=0x55914f80fbc4 "qio-channel", file=0x55914f80fb90 "/images/testvfe/sw/qemu.gerrit/include/io/channel.h", line=30, func=0x55914f80fcb8 <__func__.17257> "QIO_CHANNEL") at ../qom/object.c:872
      	#1  0x000055914f480d68 in QIO_CHANNEL (obj=0x559151b7b090) at /images/testvfe/sw/qemu.gerrit/include/io/channel.h:29
      	#2  0x000055914f4812f8 in qio_net_listener_set_client_func_full (listener=0x559151b7a720, func=0x55914f580b97 <tcp_chr_accept>, data=0x5591519f4ea0, notify=0x0, context=0x0) at ../io/net-listener.c:166
      	#3  0x000055914f580059 in tcp_chr_update_read_handler (chr=0x5591519f4ea0) at ../chardev/char-socket.c:637
      	#4  0x000055914f583dca in qemu_chr_be_update_read_handlers (s=0x5591519f4ea0, context=0x0) at ../chardev/char.c:226
      	#5  0x000055914f57b7c9 in qemu_chr_fe_set_handlers_full (b=0x559152bf23a0, fd_can_read=0x0, fd_read=0x0, fd_event=0x0, be_change=0x0, opaque=0x0, context=0x0, set_open=false, sync_state=true) at ../chardev/char-fe.c:279
      	#6  0x000055914f57b86d in qemu_chr_fe_set_handlers (b=0x559152bf23a0, fd_can_read=0x0, fd_read=0x0, fd_event=0x0, be_change=0x0, opaque=0x0, context=0x0, set_open=false) at ../chardev/char-fe.c:304
      	#7  0x000055914f378caf in vhost_user_async_close (d=0x559152bf21a0, chardev=0x559152bf23a0, vhost=0x559152bf2420, cb=0x55914f2fb8c1 <vhost_user_blk_disconnect>) at ../hw/virtio/vhost-user.c:2725
      	#8  0x000055914f2fba40 in vhost_user_blk_event (opaque=0x559152bf21a0, event=CHR_EVENT_CLOSED) at ../hw/block/vhost-user-blk.c:395
      	#9  0x000055914f58388c in chr_be_event (s=0x5591519f4ea0, event=CHR_EVENT_CLOSED) at ../chardev/char.c:61
      	#10 0x000055914f583905 in qemu_chr_be_event (s=0x5591519f4ea0, event=CHR_EVENT_CLOSED) at ../chardev/char.c:81
      	#11 0x000055914f581275 in char_socket_finalize (obj=0x5591519f4ea0) at ../chardev/char-socket.c:1083
      	#12 0x000055914f46f073 in object_deinit (obj=0x5591519f4ea0, type=0x5591519055c0) at ../qom/object.c:680
      	#13 0x000055914f46f0e5 in object_finalize (data=0x5591519f4ea0) at ../qom/object.c:694
      	#14 0x000055914f46ff06 in object_unref (objptr=0x5591519f4ea0) at ../qom/object.c:1202
      	#15 0x000055914f4715a4 in object_finalize_child_property (obj=0x559151b76c50, name=0x559151b7b250 "char3", opaque=0x5591519f4ea0) at ../qom/object.c:1747
      	#16 0x000055914f46ee86 in object_property_del_all (obj=0x559151b76c50) at ../qom/object.c:632
      	#17 0x000055914f46f0d2 in object_finalize (data=0x559151b76c50) at ../qom/object.c:693
      	#18 0x000055914f46ff06 in object_unref (objptr=0x559151b76c50) at ../qom/object.c:1202
      	#19 0x000055914f4715a4 in object_finalize_child_property (obj=0x559151b6b560, name=0x559151b76630 "chardevs", opaque=0x559151b76c50) at ../qom/object.c:1747
      	#20 0x000055914f46ef67 in object_property_del_child (obj=0x559151b6b560, child=0x559151b76c50) at ../qom/object.c:654
      	#21 0x000055914f46f042 in object_unparent (obj=0x559151b76c50) at ../qom/object.c:673
      	#22 0x000055914f58632a in qemu_chr_cleanup () at ../chardev/char.c:1189
      	#23 0x000055914f16c66c in qemu_cleanup () at ../softmmu/runstate.c:830
      	#24 0x000055914eee7b9e in qemu_default_main () at ../softmmu/main.c:38
      	#25 0x000055914eee7bcc in main (argc=86, argv=0x7ffc97cb8d88) at ../softmmu/main.c:48
      
      In char_socket_finalize after s->listener freed, event callback function
      vhost_user_blk_event will be called to handle CHR_EVENT_CLOSED.
      vhost_user_blk_event is calling qio_net_listener_set_client_func_full which
      is still using s->listener.
      
      Setting s->listener = NULL after object_unref(OBJECT(s->listener)) can
      solve this issue.
      
      Signed-off-by: default avatarYajun Wu <yajunw@nvidia.com>
      Acked-by: default avatarJiri Pirko <jiri@nvidia.com>
      Message-Id: <20230214021430.3638579-1-yajunw@nvidia.com>
      Reviewed-by: default avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      b8a7f51f
    • Philippe Mathieu-Daudé's avatar
      hw/pci: Trace IRQ routing on PCI topology · 28566eab
      Philippe Mathieu-Daudé authored
      
      Trace how IRQ are rooted from EP to RC.
      
      Signed-off-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
      Message-Id: <20230211152239.88106-3-philmd@linaro.org>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      28566eab
    • Carlos López's avatar
      libvhost-user: check for NULL when allocating a virtqueue element · 9c191605
      Carlos López authored
      
      Check the return value for malloc(), avoiding a NULL pointer
      dereference, and propagate error in function callers.
      
      Found with GCC 13 and -fanalyzer:
      
      ../subprojects/libvhost-user/libvhost-user.c: In function ‘virtqueue_alloc_element’:
      ../subprojects/libvhost-user/libvhost-user.c:2556:19: error: dereference of possibly-NULL ‘elem’ [CWE-690] [-Werror=analyzer-possible-null-dereference]
       2556 |     elem->out_num = out_num;
            |     ~~~~~~~~~~~~~~^~~~~~~~~
        ‘virtqueue_alloc_element’: event 1
          |
          | 2554 |     assert(sz >= sizeof(VuVirtqElement));
          |      |     ^~~~~~
          |      |     |
          |      |     (1) following ‘true’ branch (when ‘sz > 31’)...
          |
        ‘virtqueue_alloc_element’: events 2-4
          |
          | 2555 |     elem = malloc(out_sg_end);
          |      |     ^~~~   ~~~~~~~~~~~~~~~~~~
          |      |     |      |
          |      |     |      (3) this call could return NULL
          |      |     (2) ...to here
          | 2556 |     elem->out_num = out_num;
          |      |     ~~~~~~~~~~~~~~~~~~~~~~~
          |      |                   |
          |      |                   (4) ‘elem’ could be NULL: unchecked value from (3)
          |
      
      Signed-off-by: default avatarCarlos López <clopez@suse.de>
      Message-Id: <20230210112514.16858-1-clopez@suse.de>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      9c191605
    • Carlos López's avatar
      vhost: avoid a potential use of an uninitialized variable in vhost_svq_poll() · e4dd39c6
      Carlos López authored
      
      In vhost_svq_poll(), if vhost_svq_get_buf() fails due to a device
      providing invalid descriptors, len is left uninitialized and returned
      to the caller, potentally leaking stack data or causing undefined
      behavior.
      
      Fix this by initializing len to 0.
      
      Found with GCC 13 and -fanalyzer (abridged):
      
      ../hw/virtio/vhost-shadow-virtqueue.c: In function ‘vhost_svq_poll’:
      ../hw/virtio/vhost-shadow-virtqueue.c:538:12: warning: use of uninitialized value ‘len’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
        538 |     return len;
            |            ^~~
        ‘vhost_svq_poll’: events 1-4
          |
          |  522 | size_t vhost_svq_poll(VhostShadowVirtqueue *svq)
          |      |        ^~~~~~~~~~~~~~
          |      |        |
          |      |        (1) entry to ‘vhost_svq_poll’
          |......
          |  525 |     uint32_t len;
          |      |              ~~~
          |      |              |
          |      |              (2) region created on stack here
          |      |              (3) capacity: 4 bytes
          |......
          |  528 |         if (vhost_svq_more_used(svq)) {
          |      |             ~
          |      |             |
          |      |             (4) inlined call to ‘vhost_svq_more_used’ from ‘vhost_svq_poll’
      
          (...)
      
          |  528 |         if (vhost_svq_more_used(svq)) {
          |      |            ^~~~~~~~~~~~~~~~~~~~~~~~~
          |      |            ||
          |      |            |(8) ...to here
          |      |            (7) following ‘true’ branch...
          |......
          |  537 |     vhost_svq_get_buf(svq, &len);
          |      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          |      |     |
          |      |     (9) calling ‘vhost_svq_get_buf’ from ‘vhost_svq_poll’
          |
          +--> ‘vhost_svq_get_buf’: events 10-11
                 |
                 |  416 | static VirtQueueElement *vhost_svq_get_buf(VhostShadowVirtqueue *svq,
                 |      |                          ^~~~~~~~~~~~~~~~~
                 |      |                          |
                 |      |                          (10) entry to ‘vhost_svq_get_buf’
                 |......
                 |  423 |     if (!vhost_svq_more_used(svq)) {
                 |      |          ~
                 |      |          |
                 |      |          (11) inlined call to ‘vhost_svq_more_used’ from ‘vhost_svq_get_buf’
                 |
      
                 (...)
      
                 |
               ‘vhost_svq_get_buf’: event 14
                 |
                 |  423 |     if (!vhost_svq_more_used(svq)) {
                 |      |        ^
                 |      |        |
                 |      |        (14) following ‘false’ branch...
                 |
               ‘vhost_svq_get_buf’: event 15
                 |
                 |cc1:
                 | (15): ...to here
                 |
          <------+
          |
        ‘vhost_svq_poll’: events 16-17
          |
          |  537 |     vhost_svq_get_buf(svq, &len);
          |      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
          |      |     |
          |      |     (16) returning to ‘vhost_svq_poll’ from ‘vhost_svq_get_buf’
          |  538 |     return len;
          |      |            ~~~
          |      |            |
          |      |            (17) use of uninitialized value ‘len’ here
      
      Note by  Laurent Vivier <lvivier@redhat.com>:
      
          The return value is only used to detect an error:
      
          vhost_svq_poll
              vhost_vdpa_net_cvq_add
                  vhost_vdpa_net_load_cmd
                      vhost_vdpa_net_load_mac
                        -> a negative return is only used to detect error
                      vhost_vdpa_net_load_mq
                        -> a negative return is only used to detect error
                  vhost_vdpa_net_handle_ctrl_avail
                    -> a negative return is only used to detect error
      
      Fixes: d368c0b0 ("vhost: Do not depend on !NULL VirtQueueElement on vhost_svq_flush")
      Signed-off-by: default avatarCarlos López <clopez@suse.de>
      Message-Id: <20230213085747.19956-1-clopez@suse.de>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      e4dd39c6
    • Vladimir Sementsov-Ogievskiy's avatar
      pcie: set power indicator to off on reset by default · 1768e97b
      Vladimir Sementsov-Ogievskiy authored
      
      It should not be zero, the only valid values are ON, OFF and BLINK.
      
      Signed-off-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
      Reviewed-by: default avatarAnton Kuchin <antonkuchin@yandex-team.ru>
      Message-Id: <20230216180356.156832-13-vsementsov@yandex-team.ru>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      1768e97b
  2. Mar 02, 2023
Loading