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: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <helgaas@kernel.org>
Reviewed-by: NKeith Busch <keith.busch@intel.com>