qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] dd0ef1: e1000e: Fix possible interrupt loss w


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] dd0ef1: e1000e: Fix possible interrupt loss when using MSI
Date: Tue, 26 Jul 2022 05:29:08 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: dd0ef128669c29734a197ca9195e7ab64e20ba2c
      
https://github.com/qemu/qemu/commit/dd0ef128669c29734a197ca9195e7ab64e20ba2c
  Author: Ake Koomsin <ake@igel.co.jp>
  Date:   2022-07-26 (Tue, 26 Jul 2022)

  Changed paths:
    M hw/net/e1000e_core.c

  Log Message:
  -----------
  e1000e: Fix possible interrupt loss when using MSI

Commit "e1000e: Prevent MSI/MSI-X storms" introduced msi_causes_pending
to prevent interrupt storms problem. It was tested with MSI-X.

In case of MSI, the guest can rely solely on interrupts to clear ICR.
Upon clearing all pending interrupts, msi_causes_pending gets cleared.
However, when e1000e_itr_should_postpone() in e1000e_send_msi() returns
true, MSI never gets fired by e1000e_intrmgr_on_throttling_timer()
because msi_causes_pending is still set. This results in interrupt loss.

To prevent this, we need to clear msi_causes_pending when MSI is going
to get fired by the throttling timer. The guest can then receive
interrupts eventually.

Signed-off-by: Ake Koomsin <ake@igel.co.jp>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: 2fdac348fd3d243bb964937236af3cc27ae7af2b
      
https://github.com/qemu/qemu/commit/2fdac348fd3d243bb964937236af3cc27ae7af2b
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-07-26 (Tue, 26 Jul 2022)

  Changed paths:
    M hw/virtio/vhost-vdpa.c

  Log Message:
  -----------
  vhost: Get vring base from vq, not svq

The SVQ vring used idx usually match with the guest visible one, as long
as all the guest buffers (GPA) maps to exactly one buffer within qemu's
VA. However, as we can see in virtqueue_map_desc, a single guest buffer
could map to many buffers in SVQ vring.

Also, its also a mistake to rewind them at the source of migration.
Since VirtQueue is able to migrate the inflight descriptors, its
responsability of the destination to perform the rewind just in case it
cannot report the inflight descriptors to the device.

This makes easier to migrate between backends or to recover them in
vhost devices that support set in flight descriptors.

Fixes: 6d0b22266633 ("vdpa: Adapt vhost_vdpa_get_vring_base to SVQ")
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: 75a8ce64f6e37513698857fb4284170da163ed06
      
https://github.com/qemu/qemu/commit/75a8ce64f6e37513698857fb4284170da163ed06
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-07-26 (Tue, 26 Jul 2022)

  Changed paths:
    M hw/virtio/vhost-vdpa.c

  Log Message:
  -----------
  vdpa: Fix memory listener deletions of iova tree

vhost_vdpa_listener_region_del is always deleting the first iova entry
of the tree, since it's using the needle iova instead of the result's
one.

This was detected using a vga virtual device in the VM using vdpa SVQ.
It makes some extra memory adding and deleting, so the wrong one was
mapped / unmapped. This was undetected before since all the memory was
mappend and unmapped totally without that device, but other conditions
could trigger it too:

* mem_region was with .iova = 0, .translated_addr = (correct GPA).
* iova_tree_find_iova returned right result, but does not update
  mem_region.
* iova_tree_remove always removed region with .iova = 0. Right iova were
  sent to the device.
* Next map will fill the first region with .iova = 0, causing a mapping
  with the same iova and device complains, if the next action is a map.
* Next unmap will cause to try to unmap again iova = 0, causing the
  device to complain that no region was mapped at iova = 0.

Fixes: 34e3c94edaef ("vdpa: Add custom IOTLB translations to SVQ")
Reported-by: Lei Yang <leiyang@redhat.com>
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: 0d0275c31f00b71b49eb80bbdca2cfe244cf80fb
      
https://github.com/qemu/qemu/commit/0d0275c31f00b71b49eb80bbdca2cfe244cf80fb
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2022-07-26 (Tue, 26 Jul 2022)

  Changed paths:
    M hw/net/e1000e_core.c
    M hw/virtio/vhost-vdpa.c

  Log Message:
  -----------
  Merge tag 'net-pull-request' of https://github.com/jasowang/qemu into staging

# gpg: Signature made Tue 26 Jul 2022 09:47:24 BST
# gpg:                using RSA key EF04965B398D6211
# gpg: Good signature from "Jason Wang (Jason Wang on RedHat) 
<jasowang@redhat.com>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg:          It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 215D 46F4 8246 689E C77F  3562 EF04 965B 398D 6211

* tag 'net-pull-request' of https://github.com/jasowang/qemu:
  vdpa: Fix memory listener deletions of iova tree
  vhost: Get vring base from vq, not svq
  e1000e: Fix possible interrupt loss when using MSI

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


Compare: https://github.com/qemu/qemu/compare/616a6459d878...0d0275c31f00



reply via email to

[Prev in Thread] Current Thread [Next in Thread]