From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38593) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXMHp-0000DO-JC for qemu-devel@nongnu.org; Mon, 16 Mar 2015 00:05:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YXMHo-0006j2-7W for qemu-devel@nongnu.org; Mon, 16 Mar 2015 00:05:53 -0400 Message-ID: <1426478732.17565.227.camel@kernel.crashing.org> From: Benjamin Herrenschmidt Date: Mon, 16 Mar 2015 15:05:32 +1100 In-Reply-To: <20150316010459.GA13680@shangw> References: <1426054314-19564-1-git-send-email-gwshan@linux.vnet.ibm.com> <1426054314-19564-2-git-send-email-gwshan@linux.vnet.ibm.com> <1426283487.3643.132.camel@redhat.com> <20150316010459.GA13680@shangw> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/3] VFIO: Clear INTx pending state on EEH reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gavin Shan Cc: Alex Williamson , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, david@gibson.dropbear.id.au On Mon, 2015-03-16 at 12:04 +1100, Gavin Shan wrote: > > > (2) QEMU sends IOCTL commands to host to disable MSIx and enable INTx. At > this stage the INTx is still masked. At later point, the guest is requesting > unmasking INTx, which is captured by host. Host checks and founds pending > INTx, which is sent to QEMU. In QEMU INTx handler (vfio_intx_interrupt()), > the mmap'ed regions are disabled, "intx.pending" is set and a timer is started > to reenable mmap'ed regions if "intx.pending" is cleared there. However, > "intx.pending" is only cleared upon BAR access in slow path, which is never > happing. > > (3) After guest disables MSIx and issue EEH reset, the device driver starts > to check its firmware state by reading MMIO register, which isn't completed > by QEMU VFIO BAR slow path (Note: fast path supported by mmaped regions have > been disabled). Eventually, the guest hangs on reading MMIO register. With > this patch applied to QEMU, I didn't see the problem again. Note that it might be a good idea to disable INTx (and synchronize with a cfg read of some sort) around resetting a device. Otherwise, you may hit a known issue if the device is behind a switch and has sent the INTx "assert" message, and not the "deassert" one before it gets reset. That can cause the INTx to effectively be "stuck" in the switch preventing a subsequent one from being delivered. Cheers, Ben.