From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com ([192.55.52.88]:48755 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752506AbdLNPqm (ORCPT ); Thu, 14 Dec 2017 10:46:42 -0500 Date: Thu, 14 Dec 2017 08:50:23 -0700 From: Keith Busch To: Alex Williamson Cc: linux-pci@vger.kernel.org, bhelgaas@google.com, liudongdong3@huawei.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] PCI/DPC: Fix shared interrupt handling Message-ID: <20171214155023.GA26488@localhost.localdomain> References: <20171214151854.7578.20594.stgit@gimli.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20171214151854.7578.20594.stgit@gimli.home> Sender: linux-pci-owner@vger.kernel.org List-ID: On Thu, Dec 14, 2017 at 08:20:18AM -0700, Alex Williamson wrote: > DPC supports shared interrupts, but it plays very loosely with testing > whether the interrupt is generated by DPC before generating spurious > log messages, such as: > > dpc 0000:10:01.2:pcie010: DPC containment event, status:0x1f00 source:0x0000 > > Testing the status register for zero or -1 is not sufficient when the > device supports the RP PIO First Error Pointer register. Change this > to test whether the interrupt is enabled in the control register, > retaining the device present test, and that the status reports the > interrupt as signaled and DPC is triggered, clearing as a spurious > interrupt otherwise. > > Additionally, since the interrupt is actually serviced by a workqueue, > disable the interrupt in the control register until that completes or > else we may never see it execute due to further incoming interrupts. > A software generated DPC floods the system otherwise. > > Signed-off-by: Alex Williamson Thanks, looks good. Reviewed-by: Keith Busch