qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gavin Shan <gwshan@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Cc: aik@ozlabs.ru, agraf@suse.de,
	Gavin Shan <gwshan@linux.vnet.ibm.com>,
	alex.williamson@redhat.com, qemu-ppc@nongnu.org,
	david@gibson.dropbear.id.au
Subject: [Qemu-devel] [PATCH v2 2/3] VFIO: Disable INTx interrupt on EEH reset
Date: Tue, 17 Mar 2015 03:31:25 +1100	[thread overview]
Message-ID: <1426523486-9794-2-git-send-email-gwshan@linux.vnet.ibm.com> (raw)
In-Reply-To: <1426523486-9794-1-git-send-email-gwshan@linux.vnet.ibm.com>

When Linux guest recovers from EEH error on the following Emulex
adapter, the MSIx interrupts are disabled and the INTx emulation
is enabled. One INTx interrupt is injected to the guest by host
because of detected pending INTx interrupts on the adapter. QEMU
disables mmap'ed BAR regions and starts a timer to enable those
regions at later point the INTx interrupt handler. Unfortunately,
"VFIOPCIDevice->intx.pending" isn't cleared, meaning those disabled
mapp'ed BAR regions won't be reenabled properly. It leads to EEH
recovery failure at guest side because of hanged MMIO access.

 # lspci | grep Emulex
 0000:01:00.0 Ethernet controller: Emulex Corporation \
              OneConnect 10Gb NIC (be3) (rev 02)
 0000:01:00.1 Ethernet controller: Emulex Corporation \
              OneConnect 10Gb NIC (be3) (rev 02)

The patch disables INTx interrupt before doing EEH reset to avoid
the issue.

Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
 hw/vfio/pci.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index fca1edc..bfa3d0c 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -3340,6 +3340,14 @@ int vfio_container_eeh_event(AddressSpace *as, int32_t groupid,
          * disable it so that it can be reenabled properly. Also,
          * the cached MSIx table should be cleared as it's not
          * reflecting the contents in hardware.
+         *
+         * We might have INTx interrupt whose handler disables the
+         * memory mapped BARs. The INTx pending state can't be
+         * cleared with memory BAR access in slow path. The timer
+         * kicked by the INTx interrupt handler won't enable those
+         * disabled memory mapped BARs, which leads to hanged MMIO
+         * register access and EEH recovery failure. We simply disable
+         * INTx if it has been enabled.
          */
         QLIST_FOREACH(vbasedev, &group->device_list, next) {
             vdev = container_of(vbasedev, VFIOPCIDevice, vbasedev);
@@ -3348,6 +3356,11 @@ int vfio_container_eeh_event(AddressSpace *as, int32_t groupid,
             }
 
             msix_reset(&vdev->pdev);
+
+            /* Disable INTx */
+            if (vdev->interrupt == VFIO_INT_INTx) {
+                vfio_disable_intx(vdev);
+            }
         }
 
         break;
-- 
1.8.3.2

  reply	other threads:[~2015-03-16 16:32 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-16 16:31 [Qemu-devel] [PATCH v2 1/3] VFIO: Clear stale MSIx table during EEH reset Gavin Shan
2015-03-16 16:31 ` Gavin Shan [this message]
2015-03-17 21:16   ` [Qemu-devel] [PATCH v2 2/3] VFIO: Disable INTx interrupt on " Alex Williamson
2015-03-18  4:54     ` [Qemu-devel] [Qemu-ppc] " Gavin Shan
2015-03-20  4:01       ` Gavin Shan
2015-03-20  5:57         ` Gavin Shan
2015-03-16 16:31 ` [Qemu-devel] [PATCH v2 3/3] sPAPR: Reenable EEH functionality on reboot Gavin Shan
2015-03-17 21:09 ` [Qemu-devel] [PATCH v2 1/3] VFIO: Clear stale MSIx table during EEH reset Alex Williamson
2015-03-17 23:26   ` Gavin Shan
2015-03-23  5:05     ` Gavin Shan
2015-03-20  6:04 ` David Gibson
2015-03-20  6:27   ` [Qemu-devel] [Qemu-ppc] " Gavin Shan
2015-03-23  5:06     ` David Gibson
2015-03-23  5:25       ` Gavin Shan
2015-03-24  5:41         ` David Gibson
2015-03-24  6:24           ` Gavin Shan
2015-03-24  6:54             ` David Gibson
2015-03-24 12:53               ` Alex Williamson
2015-03-26  0:53                 ` Gavin Shan
2015-03-26  1:10                   ` David Gibson
2015-03-26  1:30                     ` Gavin Shan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1426523486-9794-2-git-send-email-gwshan@linux.vnet.ibm.com \
    --to=gwshan@linux.vnet.ibm.com \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).