Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp44278pxb; Thu, 21 Jan 2021 00:26:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJxDrsWwz2dmfUFez7xl03dcw2VjUQbPKLvPwivrzOhqg6HAMc9+kyq3H6yRRhn7npGs6nk0 X-Received: by 2002:a17:906:7215:: with SMTP id m21mr8370418ejk.248.1611217612445; Thu, 21 Jan 2021 00:26:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611217612; cv=none; d=google.com; s=arc-20160816; b=UJKaYDmqBkSMPsvu6y9bxImu16N41XOWv57MBQo0SI1bWxz+A2jShLZZpWkUbDJJxk av/R7TY1FrjFt0HVfgOb3jpqRlFJQGGRf4V9QGohTdgaeHB02OcAgJYV/MpbkAKiwko2 rrHdRTBdhEgAfuY6xLB0DIqQ0y8CFQPm1b74RV5mMqzqmWPbjLxSCF3b3cU/5CyfhCQB OHrz/vezVjvj73cUK/ROLLbppIJZz/mC/LXEayKyGSr8EVSShlsixhvruszHiO9wJ2VO Ii8c20Yyh4vldE6cjvvPMqByKyuBfBfAEEXY7nyNNMz7IZtNHka5uAvhSKqGgmo/dtLS yPfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature; bh=0gba4+t4e2AipgLr57aF/TlL6LFHCc9J8pUh2gVcris=; b=ga67Ee8Vc09Dka2SoQK+Q7P2yxZTd4rFFUpDsraBDEU6NL3uDaEApx7Nb5IS01TY4g xaAIp/B9w9Siv7M2JtvKMAi3RTpbSikYVktJhBsXEHVShSK6pP4wJfZSOvmK675T7ENl OJ+DTnxV24c3DbDYHnP9wynSmMAvuB5phsiPMddDZ8vLcqMyf42Pos5ZnNz8OJ6BN/ee lk0p03nto8PwCX9CYgCFIAKYfqdLCg30pREZNgaVQeonGOiZe/iVAWFbgASS4aCCf9w1 lVS1p80J5eZrJHQTmbEUj/lptPIpAhDuH6DOMt8COB7tlcNKfPX3ukDpFXlV8EgFqO2N 3rfA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BcpzMVeX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x11si1479231ejs.461.2021.01.21.00.26.28; Thu, 21 Jan 2021 00:26:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BcpzMVeX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727029AbhAUIZ2 (ORCPT + 99 others); Thu, 21 Jan 2021 03:25:28 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:60498 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726716AbhAUIWb (ORCPT ); Thu, 21 Jan 2021 03:22:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611217264; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0gba4+t4e2AipgLr57aF/TlL6LFHCc9J8pUh2gVcris=; b=BcpzMVeXNkj07EDc1NvNPrD3UGpnPj81WtvN2iBHpA19n4MdLpJI/OVw7ui7dDu6z1DtiO PoL5f7PudjaFgrOe7B8Bz7gaFfASpfxO73CPY0n255ghgFZiPKKoU2XofmyxedY2Rrm3Wo ZnIio3scO5iB+X/vY2O0ZnXWo7vaMew= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-471-RYrER6NZN9yxIYxlQV358g-1; Thu, 21 Jan 2021 03:20:59 -0500 X-MC-Unique: RYrER6NZN9yxIYxlQV358g-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4DEF310054FF; Thu, 21 Jan 2021 08:20:57 +0000 (UTC) Received: from gondolin (ovpn-113-94.ams2.redhat.com [10.36.113.94]) by smtp.corp.redhat.com (Postfix) with ESMTP id 546B871C9A; Thu, 21 Jan 2021 08:20:47 +0000 (UTC) Date: Thu, 21 Jan 2021 09:20:44 +0100 From: Cornelia Huck To: Halil Pasic Cc: Tony Krowiak , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, stable@vger.kernel.org, Pierre Morel , Harald Freudenberger , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , mjrosato@linux.ibm.com, alex.williamson@redhat.com, kwankhede@nvidia.com, fiuczy@linux.ibm.com, frankja@linux.ibm.com, david@redhat.com Subject: Re: [PATCH 1/1] s390/vfio-ap: No need to disable IRQ after queue reset Message-ID: <20210121092044.628b77c7.cohuck@redhat.com> In-Reply-To: <20210121072008.76523-1-pasic@linux.ibm.com> References: <20210121072008.76523-1-pasic@linux.ibm.com> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 21 Jan 2021 08:20:08 +0100 Halil Pasic wrote: > From: Tony Krowiak > > The queues assigned to a matrix mediated device are currently reset when: > > * The VFIO_DEVICE_RESET ioctl is invoked > * The mdev fd is closed by userspace (QEMU) > * The mdev is removed from sysfs. > > Immediately after the reset of a queue, a call is made to disable > interrupts for the queue. This is entirely unnecessary because the reset of > a queue disables interrupts, so this will be removed. > > Furthermore, vfio_ap_irq_disable() does an unconditional PQAP/AQIC which > can result in a specification exception (when the corresponding facility > is not available), so this is actually a bugfix. > > Signed-off-by: Tony Krowiak > [pasic@linux.ibm.com: minor rework before merging] > Reviewed-by: Halil Pasic > Signed-off-by: Halil Pasic > Fixes: ec89b55e3bce ("s390: ap: implement PAPQ AQIC interception in kernel") > Cc: > > --- > > Since it turned out disabling the interrupts via PQAP/AQIC is not only > unnecesary but also buggy, we decided to put this patch, which > used to be apart of the series https://lkml.org/lkml/2020/12/22/757 on the fast > lane. > > If the backports turn out to be a bother, which I hope won't be the case > not, I am happy to help with those. > > --- > drivers/s390/crypto/vfio_ap_drv.c | 6 +- > drivers/s390/crypto/vfio_ap_ops.c | 100 ++++++++++++++++---------- > drivers/s390/crypto/vfio_ap_private.h | 12 ++-- > 3 files changed, 69 insertions(+), 49 deletions(-) > (...) > diff --git a/drivers/s390/crypto/vfio_ap_private.h b/drivers/s390/crypto/vfio_ap_private.h > index f46dde56b464..28e9d9989768 100644 > --- a/drivers/s390/crypto/vfio_ap_private.h > +++ b/drivers/s390/crypto/vfio_ap_private.h > @@ -88,11 +88,6 @@ struct ap_matrix_mdev { > struct mdev_device *mdev; > }; > > -extern int vfio_ap_mdev_register(void); > -extern void vfio_ap_mdev_unregister(void); > -int vfio_ap_mdev_reset_queue(unsigned int apid, unsigned int apqi, > - unsigned int retry); > - > struct vfio_ap_queue { > struct ap_matrix_mdev *matrix_mdev; > unsigned long saved_pfn; > @@ -100,5 +95,10 @@ struct vfio_ap_queue { > #define VFIO_AP_ISC_INVALID 0xff > unsigned char saved_isc; > }; > -struct ap_queue_status vfio_ap_irq_disable(struct vfio_ap_queue *q); > + > +int vfio_ap_mdev_register(void); > +void vfio_ap_mdev_unregister(void); Nit: was moving these two necessary? > +int vfio_ap_mdev_reset_queue(struct vfio_ap_queue *q, > + unsigned int retry); > + > #endif /* _VFIO_AP_PRIVATE_H_ */ > > base-commit: 9791581c049c10929e97098374dd1716a81fefcc Anyway, if I didn't entangle myself in the various branches, this seems sane. Reviewed-by: Cornelia Huck