qemu-commits
[Top][All Lists]
Advanced

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

[Qemu-commits] [qemu/qemu] 6d17a0: vfio/pci: Fix regression in MSI routi


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] 6d17a0: vfio/pci: Fix regression in MSI routing configurat...
Date: Fri, 16 Sep 2016 04:00:10 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 6d17a018d09801a2b18133a4febd81433bb0cf85
      
https://github.com/qemu/qemu/commit/6d17a018d09801a2b18133a4febd81433bb0cf85
  Author: David Gibson <address@hidden>
  Date:   2016-09-15 (Thu, 15 Sep 2016)

  Changed paths:
    M hw/vfio/pci.c

  Log Message:
  -----------
  vfio/pci: Fix regression in MSI routing configuration

d1f6af6 "kvm-irqchip: simplify kvm_irqchip_add_msi_route" was a cleanup
of kvmchip routing configuration, that was mostly intended for x86.
However, it also contains a subtle change in behaviour which breaks EEH[1]
error recovery on certain VFIO passthrough devices on spapr guests.  So far
it's only been seen on a BCM5719 NIC on a POWER8 server, but there may be
other hardware with the same problem.  It's also possible there could be
circumstances where it causes a bug on x86 as well, though I don't know of
any obvious candidates.

Prior to d1f6af6, both vfio_msix_vector_do_use() and
vfio_add_kvm_msi_virq() used msg == NULL as a special flag to mark this
as the "dummy" vector used to make the host hardware state sync with the
guest expected hardware state in terms of MSI configuration.

Specifically that flag caused vfio_add_kvm_msi_virq() to become a no-op,
meaning the dummy irq would always be delivered via qemu. d1f6af6 changed
vfio_add_kvm_msi_virq() so it takes a vector number instead of the msg
parameter, and determines the correct message itself.  The test for !msg
was removed, and not replaced with anything there or in the caller.

With an spapr guest which has a VFIO device, if an EEH error occurs on the
host hardware, then the device will be isolated then reset.  This is a
combination of host and guest action, mediated by some EEH related
hypercalls.  I haven't fully traced the mechanics, but somehow installing
the kvm irqchip route for the dummy irq on the BCM5719 means that after EEH
reset and recovery, at least some irqs are no longer delivered to the
guest.

In particular, the guest never gets the link up event, and so the NIC is
effectively dead.

[1] EEH (Enhanced Error Handling) is an IBM POWER server specific PCI-*
    error reporting and recovery mechanism.  The concept is somewhat
    similar to PCI-E AER, but the details are different.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1373802

Cc: Alex Williamson <address@hidden>
Cc: Peter Xu <address@hidden>
Cc: Gavin Shan <address@hidden>
Signed-off-by: David Gibson <address@hidden>
Cc: address@hidden
Fixes: d1f6af6a17a6 ("kvm-irqchip: simplify kvm_irqchip_add_msi_route")
Signed-off-by: Alex Williamson <address@hidden>


  Commit: ebc231d7daf1f41b23d8b6a6d1234800b86e5fe2
      
https://github.com/qemu/qemu/commit/ebc231d7daf1f41b23d8b6a6d1234800b86e5fe2
  Author: Peter Maydell <address@hidden>
  Date:   2016-09-15 (Thu, 15 Sep 2016)

  Changed paths:
    M hw/vfio/pci.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/awilliam/tags/vfio-fixes-20160915.0' 
into staging

VFIO fixes 2016-09-15

Fix a 2.7.0 regression affecting POWER8 systems in relation to EEH,
possibly extending to subtle changes for other devices and archs.
(David Gibson)

# gpg: Signature made Thu 15 Sep 2016 18:31:42 BST
# gpg:                using RSA key 0x239B9B6E3BB08B22
# gpg: Good signature from "Alex Williamson <address@hidden>"
# gpg:                 aka "Alex Williamson <address@hidden>"
# gpg:                 aka "Alex Williamson <address@hidden>"
# gpg:                 aka "Alex Williamson <address@hidden>"
# Primary key fingerprint: 42F6 C04E 540B D1A9 9E7B  8A90 239B 9B6E 3BB0 8B22

* remotes/awilliam/tags/vfio-fixes-20160915.0:
  vfio/pci: Fix regression in MSI routing configuration

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


Compare: https://github.com/qemu/qemu/compare/5f473241ac59...ebc231d7daf1

reply via email to

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