Message ID | 20231020204838.409521-1-akrowiak@linux.ibm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2010:b0:403:3b70:6f57 with SMTP id fe16csp1316835vqb; Fri, 20 Oct 2023 13:49:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEJ+RdlZxHUhD7Fcr8rP2jiOBdBSu3yHNJyrF8f1tzQwnl+waprCKmtT1cBXAW+tIG+UAsu X-Received: by 2002:a17:903:41c3:b0:1ca:8468:f05e with SMTP id u3-20020a17090341c300b001ca8468f05emr3234517ple.29.1697834952449; Fri, 20 Oct 2023 13:49:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697834952; cv=none; d=google.com; s=arc-20160816; b=UkFPVMuLCtM+/7WHIoFP3LqMS3RnYHp4hHeSGBh7XxY6vAxNEp8V2zRCKUqORCiUWh 8X9ondqERgHjhBZSp/5mU44/eM6z9JQgAT8UCY8lpv9n4IgERfmLIWQCTI37emYymrGJ 4eO38kWsLy34+4xuyNYnmAjUOMVS039iT4vAe2V7Q8Y3GoyUO7hmJOt1eMh8HP+h1FdS u9v/ROcGnxb17m5qEzwPfQuVD+aSoI8OR4UmHbbz3EUJZFAmz7uxzQcQRPVRsNbtS4/e s9wqQhbj7k19BTmx40phrbDyMLShTQ7g6TGKbE/q4F3GKHzicq0oCKDEBq7Qp4LlCJS8 g4Zg== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=Yhoq0dxrpX3TpGKNPe1ltxOKvYmmrUr2BhsB7idTqzQ=; fh=+rhJBm3naSW9kDydXTcpyvHV96mQrbUifVLl1LeGCeA=; b=RviwMWRlCDTdDaQ+29OBgw4VNh28lqAo8iEsbNG6GbUIt/+HTesBIMNXasqio+QRfP kZCAILLasdnIh+RmdPLD8lYZ0G49O4Kob7pQY5St29wfEH+XpZ2KOZKsMxGfGcJ0mBlg 1yCh2nDglnerzoGEAldiDzaV+BL9OtKqk8Guf17mPh5Aw73qnz0Lm4i36vY90os5vvU7 MQgZ8ULxnSXq/tQT78opFQTfE9KjN0VmuTBILYKrkGzCMHbB2wDDHzEdGkl2NvKAcS86 Z/LKDCvGdH5cYK8/324XE2PYpuLOMd501sSUVmj+iI2ztdbcRDa6k4Tr5bLEJYoXyMHj MycA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=MgUhH2r2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id u14-20020a170902e5ce00b001ca8e7953besi2681387plf.497.2023.10.20.13.49.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Oct 2023 13:49:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=MgUhH2r2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 9E735807453A; Fri, 20 Oct 2023 13:49:09 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230522AbjJTUsq (ORCPT <rfc822;a1648639935@gmail.com> + 26 others); Fri, 20 Oct 2023 16:48:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230117AbjJTUsp (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 20 Oct 2023 16:48:45 -0400 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B92EDBF; Fri, 20 Oct 2023 13:48:43 -0700 (PDT) Received: from pps.filterd (m0353727.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 39KKgCbT002542; Fri, 20 Oct 2023 20:48:43 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : date : message-id : mime-version : content-transfer-encoding; s=pp1; bh=Yhoq0dxrpX3TpGKNPe1ltxOKvYmmrUr2BhsB7idTqzQ=; b=MgUhH2r2QfQlDEGIbVSvyCdO1A2nYvtMWTzIaki9sbvYYFklfWgDCRoQNC5Nay4t2L7/ H7xL4dV8IBZNww2AghZRAQ5Ko+ziYMur7JvQqk8ghzoXlDtnSrREjR5392yJih4jufmI z+2AJBurlsttEWzQkQN3X/1PNF6rO8Oa8zzG4HnbAiLnLDffncfnVSM7y9rR1ZTQAMQM JYAr++RngRbUWcIHDljnubEkiO1olxxmONYhcYDKx9hrNcAwN6XmqoQtn6gYKWIFrs52 /znAzi1b+PMfjimX5E/FOD5bsXc51iNI91FcPsKYvN/+f+ukpInP64yPxg4Kv1AYZG8Q ow== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3tv0tk07ty-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2023 20:48:43 +0000 Received: from m0353727.ppops.net (m0353727.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 39KKglu0004392; Fri, 20 Oct 2023 20:48:42 GMT Received: from ppma21.wdc07v.mail.ibm.com (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3tv0tk07t6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2023 20:48:42 +0000 Received: from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1]) by ppma21.wdc07v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 39KKIR77024205; Fri, 20 Oct 2023 20:48:41 GMT Received: from smtprelay01.wdc07v.mail.ibm.com ([172.16.1.68]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3tuc2977h2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2023 20:48:41 +0000 Received: from smtpav01.dal12v.mail.ibm.com (smtpav01.dal12v.mail.ibm.com [10.241.53.100]) by smtprelay01.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 39KKmeci27263626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Oct 2023 20:48:40 GMT Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4ACA35805D; Fri, 20 Oct 2023 20:48:40 +0000 (GMT) Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7C50F58059; Fri, 20 Oct 2023 20:48:39 +0000 (GMT) Received: from li-2c1e724c-2c76-11b2-a85c-ae42eaf3cb3d.ibm.com.com (unknown [9.61.44.83]) by smtpav01.dal12v.mail.ibm.com (Postfix) with ESMTP; Fri, 20 Oct 2023 20:48:39 +0000 (GMT) From: Tony Krowiak <akrowiak@linux.ibm.com> To: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: jjherne@linux.ibm.com, pasic@linux.ibm.com, borntraeger@linux.ibm.com, frankja@linux.ibm.com, imbrenda@linux.ibm.com, david@redhat.com, stable@vger.kernel.org Subject: [PATCH] s390/vfio-ap: fix sysfs status attribute for AP queue devices Date: Fri, 20 Oct 2023 16:48:35 -0400 Message-ID: <20231020204838.409521-1-akrowiak@linux.ibm.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: ptKSrGG7XvvzpbUdR3T97HTB6g-QQpxD X-Proofpoint-ORIG-GUID: mVxkVwVB00tUJmAdfDS7gFvl3AyJMGQd X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-20_10,2023-10-19_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 adultscore=0 malwarescore=0 phishscore=0 suspectscore=0 impostorscore=0 mlxlogscore=999 clxscore=1015 spamscore=0 lowpriorityscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2310170001 definitions=main-2310200176 X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Fri, 20 Oct 2023 13:49:09 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780308983090674059 X-GMAIL-MSGID: 1780308983090674059 |
Series |
s390/vfio-ap: fix sysfs status attribute for AP queue devices
|
|
Commit Message
Anthony Krowiak
Oct. 20, 2023, 8:48 p.m. UTC
The 'status' attribute for AP queue devices bound to the vfio_ap device
driver displays incorrect status when the mediated device is attached to a
guest, but the queue device is not passed through. In the current
implementation, the status displayed is 'in_use' which is not correct; it
should be 'assigned'. This can happen if one of the queue devices
associated with a given adapter is not bound to the vfio_ap device driver.
For example:
Queues listed in /sys/bus/ap/drivers/vfio_ap:
14.0005
14.0006
14.000d
16.0006
16.000d
Queues listed in /sys/devices/vfio_ap/matrix/$UUID/matrix
14.0005
14.0006
14.000d
16.0005
16.0006
16.000d
Queues listed in /sys/devices/vfio_ap/matrix/$UUID/guest_matrix
14.0005
14.0006
14.000d
The reason no queues for adapter 0x16 are listed in the guest_matrix is
because queue 16.0005 is not bound to the vfio_ap device driver, so no
queue associated with the adapter is passed through to the guest;
therefore, each queue device for adapter 0x16 should display 'assigned'
instead of 'in_use', because those queues are not in use by a guest, but
only assigned to the mediated device.
Let's check the AP configuration for the guest to determine whether a
queue device is passed through before displaying a status of 'in_use'.
Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
Fixes: f139862b92cf ("s390/vfio-ap: add status attribute to AP queue device's sysfs dir")
Cc: stable@vger.kernel.org
---
drivers/s390/crypto/vfio_ap_ops.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
Comments
PING This patch is pretty straight forward, does anyone see a reason why this shouldn't be integrated? On 10/20/23 16:48, Tony Krowiak wrote: > The 'status' attribute for AP queue devices bound to the vfio_ap device > driver displays incorrect status when the mediated device is attached to a > guest, but the queue device is not passed through. In the current > implementation, the status displayed is 'in_use' which is not correct; it > should be 'assigned'. This can happen if one of the queue devices > associated with a given adapter is not bound to the vfio_ap device driver. > For example: > > Queues listed in /sys/bus/ap/drivers/vfio_ap: > 14.0005 > 14.0006 > 14.000d > 16.0006 > 16.000d > > Queues listed in /sys/devices/vfio_ap/matrix/$UUID/matrix > 14.0005 > 14.0006 > 14.000d > 16.0005 > 16.0006 > 16.000d > > Queues listed in /sys/devices/vfio_ap/matrix/$UUID/guest_matrix > 14.0005 > 14.0006 > 14.000d > > The reason no queues for adapter 0x16 are listed in the guest_matrix is > because queue 16.0005 is not bound to the vfio_ap device driver, so no > queue associated with the adapter is passed through to the guest; > therefore, each queue device for adapter 0x16 should display 'assigned' > instead of 'in_use', because those queues are not in use by a guest, but > only assigned to the mediated device. > > Let's check the AP configuration for the guest to determine whether a > queue device is passed through before displaying a status of 'in_use'. > > Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> > Fixes: f139862b92cf ("s390/vfio-ap: add status attribute to AP queue device's sysfs dir") > Cc: stable@vger.kernel.org > --- > drivers/s390/crypto/vfio_ap_ops.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c > index 4db538a55192..871c14a6921f 100644 > --- a/drivers/s390/crypto/vfio_ap_ops.c > +++ b/drivers/s390/crypto/vfio_ap_ops.c > @@ -1976,6 +1976,7 @@ static ssize_t status_show(struct device *dev, > { > ssize_t nchars = 0; > struct vfio_ap_queue *q; > + unsigned long apid, apqi; > struct ap_matrix_mdev *matrix_mdev; > struct ap_device *apdev = to_ap_dev(dev); > > @@ -1984,7 +1985,11 @@ static ssize_t status_show(struct device *dev, > matrix_mdev = vfio_ap_mdev_for_queue(q); > > if (matrix_mdev) { > - if (matrix_mdev->kvm) > + apid = AP_QID_CARD(q->apqn); > + apqi = AP_QID_QUEUE(q->apqn); > + if (matrix_mdev->kvm && > + test_bit_inv(apid, matrix_mdev->shadow_apcb.apm) && > + test_bit_inv(apqi, matrix_mdev->shadow_apcb.aqm)) > nchars = scnprintf(buf, PAGE_SIZE, "%s\n", > AP_QUEUE_IN_USE); > else
On Fri, 20 Oct 2023 16:48:35 -0400 Tony Krowiak <akrowiak@linux.ibm.com> wrote: > The 'status' attribute for AP queue devices bound to the vfio_ap device > driver displays incorrect status when the mediated device is attached to a > guest, but the queue device is not passed through. In the current > implementation, the status displayed is 'in_use' which is not correct; it > should be 'assigned'. This can happen if one of the queue devices > associated with a given adapter is not bound to the vfio_ap device driver. > For example: > > Queues listed in /sys/bus/ap/drivers/vfio_ap: > 14.0005 > 14.0006 > 14.000d > 16.0006 > 16.000d > > Queues listed in /sys/devices/vfio_ap/matrix/$UUID/matrix > 14.0005 > 14.0006 > 14.000d > 16.0005 > 16.0006 > 16.000d > > Queues listed in /sys/devices/vfio_ap/matrix/$UUID/guest_matrix > 14.0005 > 14.0006 > 14.000d > > The reason no queues for adapter 0x16 are listed in the guest_matrix is > because queue 16.0005 is not bound to the vfio_ap device driver, so no > queue associated with the adapter is passed through to the guest; > therefore, each queue device for adapter 0x16 should display 'assigned' > instead of 'in_use', because those queues are not in use by a guest, but > only assigned to the mediated device. > > Let's check the AP configuration for the guest to determine whether a > queue device is passed through before displaying a status of 'in_use'. > > Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> > Fixes: f139862b92cf ("s390/vfio-ap: add status attribute to AP queue device's sysfs dir") Acked-by: Halil Pasic <pasic@linux.ibm.com> I'm not sure if there is documentation. I assume there is no additional documentation except for the code and the commit messages on what those actually mean. So there is no way to cross-check and no need to update it. I personally don't feel like having clarity on these states. In use does not actually mean that the guest is actually using it: the guest can happily ignore the queue. The unassigned is pretty clear. What "assigned" vs "in use" is supposed to express, not so much to me. I don't think this fix qualifies for the stable process, but it has been a while since I've looked at the corresponding process documentation. > Cc: stable@vger.kernel.org
On 2023-11-06 17:03, Tony Krowiak wrote: > PING > This patch is pretty straight forward, does anyone see a reason why > this shouldn't be integrated? > > On 10/20/23 16:48, Tony Krowiak wrote: >> The 'status' attribute for AP queue devices bound to the vfio_ap >> device >> driver displays incorrect status when the mediated device is attached >> to a >> guest, but the queue device is not passed through. In the current >> implementation, the status displayed is 'in_use' which is not correct; >> it >> should be 'assigned'. This can happen if one of the queue devices >> associated with a given adapter is not bound to the vfio_ap device >> driver. >> For example: >> >> Queues listed in /sys/bus/ap/drivers/vfio_ap: >> 14.0005 >> 14.0006 >> 14.000d >> 16.0006 >> 16.000d >> >> Queues listed in /sys/devices/vfio_ap/matrix/$UUID/matrix >> 14.0005 >> 14.0006 >> 14.000d >> 16.0005 >> 16.0006 >> 16.000d >> >> Queues listed in /sys/devices/vfio_ap/matrix/$UUID/guest_matrix >> 14.0005 >> 14.0006 >> 14.000d >> >> The reason no queues for adapter 0x16 are listed in the guest_matrix >> is >> because queue 16.0005 is not bound to the vfio_ap device driver, so no >> queue associated with the adapter is passed through to the guest; >> therefore, each queue device for adapter 0x16 should display >> 'assigned' >> instead of 'in_use', because those queues are not in use by a guest, >> but >> only assigned to the mediated device. >> >> Let's check the AP configuration for the guest to determine whether a >> queue device is passed through before displaying a status of 'in_use'. >> >> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> >> Fixes: f139862b92cf ("s390/vfio-ap: add status attribute to AP queue >> device's sysfs dir") >> Cc: stable@vger.kernel.org >> --- >> drivers/s390/crypto/vfio_ap_ops.c | 7 ++++++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/s390/crypto/vfio_ap_ops.c >> b/drivers/s390/crypto/vfio_ap_ops.c >> index 4db538a55192..871c14a6921f 100644 >> --- a/drivers/s390/crypto/vfio_ap_ops.c >> +++ b/drivers/s390/crypto/vfio_ap_ops.c >> @@ -1976,6 +1976,7 @@ static ssize_t status_show(struct device *dev, >> { >> ssize_t nchars = 0; >> struct vfio_ap_queue *q; >> + unsigned long apid, apqi; >> struct ap_matrix_mdev *matrix_mdev; >> struct ap_device *apdev = to_ap_dev(dev); >> @@ -1984,7 +1985,11 @@ static ssize_t status_show(struct device >> *dev, >> matrix_mdev = vfio_ap_mdev_for_queue(q); >> if (matrix_mdev) { >> - if (matrix_mdev->kvm) >> + apid = AP_QID_CARD(q->apqn); >> + apqi = AP_QID_QUEUE(q->apqn); >> + if (matrix_mdev->kvm && >> + test_bit_inv(apid, matrix_mdev->shadow_apcb.apm) && >> + test_bit_inv(apqi, matrix_mdev->shadow_apcb.aqm)) >> nchars = scnprintf(buf, PAGE_SIZE, "%s\n", >> AP_QUEUE_IN_USE); >> else I can give you an Acked-by: Harald Freudenberger <freude@linux.ibm.com> for this. Your explanation sounds sane to me and fixes a wrong display. However, I am not familiar with the code so, I can't tell if that's correct. Just a remark: How can it happen that one queue is not bound to the vfio dd? Didn't we actively remove the unbind possibility from the sysfs for devices assigned to the vfio dd?
On 11/7/23 03:07, Harald Freudenberger wrote: > On 2023-11-06 17:03, Tony Krowiak wrote: >> PING >> This patch is pretty straight forward, does anyone see a reason why >> this shouldn't be integrated? >> >> On 10/20/23 16:48, Tony Krowiak wrote: >>> The 'status' attribute for AP queue devices bound to the vfio_ap device >>> driver displays incorrect status when the mediated device is attached >>> to a >>> guest, but the queue device is not passed through. In the current >>> implementation, the status displayed is 'in_use' which is not >>> correct; it >>> should be 'assigned'. This can happen if one of the queue devices >>> associated with a given adapter is not bound to the vfio_ap device >>> driver. >>> For example: >>> >>> Queues listed in /sys/bus/ap/drivers/vfio_ap: >>> 14.0005 >>> 14.0006 >>> 14.000d >>> 16.0006 >>> 16.000d >>> >>> Queues listed in /sys/devices/vfio_ap/matrix/$UUID/matrix >>> 14.0005 >>> 14.0006 >>> 14.000d >>> 16.0005 >>> 16.0006 >>> 16.000d >>> >>> Queues listed in /sys/devices/vfio_ap/matrix/$UUID/guest_matrix >>> 14.0005 >>> 14.0006 >>> 14.000d >>> >>> The reason no queues for adapter 0x16 are listed in the guest_matrix is >>> because queue 16.0005 is not bound to the vfio_ap device driver, so no >>> queue associated with the adapter is passed through to the guest; >>> therefore, each queue device for adapter 0x16 should display 'assigned' >>> instead of 'in_use', because those queues are not in use by a guest, but >>> only assigned to the mediated device. >>> >>> Let's check the AP configuration for the guest to determine whether a >>> queue device is passed through before displaying a status of 'in_use'. >>> >>> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> >>> Fixes: f139862b92cf ("s390/vfio-ap: add status attribute to AP queue >>> device's sysfs dir") >>> Cc: stable@vger.kernel.org >>> --- >>> drivers/s390/crypto/vfio_ap_ops.c | 7 ++++++- >>> 1 file changed, 6 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/s390/crypto/vfio_ap_ops.c >>> b/drivers/s390/crypto/vfio_ap_ops.c >>> index 4db538a55192..871c14a6921f 100644 >>> --- a/drivers/s390/crypto/vfio_ap_ops.c >>> +++ b/drivers/s390/crypto/vfio_ap_ops.c >>> @@ -1976,6 +1976,7 @@ static ssize_t status_show(struct device *dev, >>> { >>> ssize_t nchars = 0; >>> struct vfio_ap_queue *q; >>> + unsigned long apid, apqi; >>> struct ap_matrix_mdev *matrix_mdev; >>> struct ap_device *apdev = to_ap_dev(dev); >>> @@ -1984,7 +1985,11 @@ static ssize_t status_show(struct device *dev, >>> matrix_mdev = vfio_ap_mdev_for_queue(q); >>> if (matrix_mdev) { >>> - if (matrix_mdev->kvm) >>> + apid = AP_QID_CARD(q->apqn); >>> + apqi = AP_QID_QUEUE(q->apqn); >>> + if (matrix_mdev->kvm && >>> + test_bit_inv(apid, matrix_mdev->shadow_apcb.apm) && >>> + test_bit_inv(apqi, matrix_mdev->shadow_apcb.aqm)) >>> nchars = scnprintf(buf, PAGE_SIZE, "%s\n", >>> AP_QUEUE_IN_USE); >>> else > > I can give you an > Acked-by: Harald Freudenberger <freude@linux.ibm.com> > for this. Your explanation sounds sane to me and fixes a wrong > display. However, I am not familiar with the code so, I can't tell > if that's correct. > Just a remark: How can it happen that one queue is not bound to the vfio > dd? > Didn't we actively remove the unbind possibility from the sysfs for devices > assigned to the vfio dd? A device bound to the vfio_ap device driver can be manually unbound; however, it can not be unbound by the AP bus via a change to the apmask/aqmask attributes if it is assigned to a mediated device. At one point I wanted to remove the unbind sysfs attribute, but as I recall I was talked out of it.
diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c index 4db538a55192..871c14a6921f 100644 --- a/drivers/s390/crypto/vfio_ap_ops.c +++ b/drivers/s390/crypto/vfio_ap_ops.c @@ -1976,6 +1976,7 @@ static ssize_t status_show(struct device *dev, { ssize_t nchars = 0; struct vfio_ap_queue *q; + unsigned long apid, apqi; struct ap_matrix_mdev *matrix_mdev; struct ap_device *apdev = to_ap_dev(dev); @@ -1984,7 +1985,11 @@ static ssize_t status_show(struct device *dev, matrix_mdev = vfio_ap_mdev_for_queue(q); if (matrix_mdev) { - if (matrix_mdev->kvm) + apid = AP_QID_CARD(q->apqn); + apqi = AP_QID_QUEUE(q->apqn); + if (matrix_mdev->kvm && + test_bit_inv(apid, matrix_mdev->shadow_apcb.apm) && + test_bit_inv(apqi, matrix_mdev->shadow_apcb.aqm)) nchars = scnprintf(buf, PAGE_SIZE, "%s\n", AP_QUEUE_IN_USE); else