On 10/30/19 8:44 AM, Harald Freudenberger wrote:
On 29.10.19 23:09, Tony Krowiak wrote:
From: aekrowia <akrowiak@xxxxxxxxxxxxx>
When an AP adapter card is configured off via the SE or the SCLP
Deconfigure Adjunct Processor command and the AP bus subsequently detects
that the adapter card is no longer in the AP configuration, the card
device representing the adapter card as well as each of its associated
AP queue devices will be removed by the AP bus. If one or more of the
affected queue devices is bound to the VFIO AP device driver, its remove
callback will be invoked for each queue to be removed. The remove callback
resets the queue and disables IRQ processing. If interrupt processing was
never enabled for the queue, disabling IRQ processing will fail resulting
in a kernel OOPS.
This patch verifies IRQ processing is enabled before attempting to disable
interrupts for the queue.
Signed-off-by: Tony Krowiak <akrowiak@xxxxxxxxxxxxx>
Signed-off-by: aekrowia <akrowiak@xxxxxxxxxxxxx>
---
drivers/s390/crypto/vfio_ap_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/s390/crypto/vfio_ap_drv.c b/drivers/s390/crypto/vfio_ap_drv.c
index be2520cc010b..42d8308fd3a1 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -79,7 +79,8 @@ static void vfio_ap_queue_dev_remove(struct ap_device *apdev)
apid = AP_QID_CARD(q->apqn);
apqi = AP_QID_QUEUE(q->apqn);
vfio_ap_mdev_reset_queue(apid, apqi, 1);
- vfio_ap_irq_disable(q);
+ if (q->saved_isc != VFIO_AP_ISC_INVALID)
+ vfio_ap_irq_disable(q);
kfree(q);
mutex_unlock(&matrix_dev->lock);
}
Reset of an APQN does also clear IRQ processing. I don't say that the
resources associated with IRQ handling for the APQN are also cleared.
But when you call PQAP(AQIC) after an PQAP(RAPQ) or PQAP(ZAPQ)
it is superfluous. However, there should not appear any kernel OOPS.
So can you please give me more details about this kernel oops - maybe
I need to add exception handler code to the inline ap_aqic() function.
regards, Harald Freudenberger
Hi Tony,
wasn't it already solved by the patch 5c4c2126 from Christian ?
Can you send the trace to me please?
Thanks,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
