Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp433496imm; Fri, 21 Sep 2018 02:42:08 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbzWx9UqJFxmWUXNsfQvaIctE8CI4avIZKHfFI1KV1R2Aetmn4ge9/m+8oZYE4MInJjaQs/ X-Received: by 2002:a17:902:7e45:: with SMTP id a5-v6mr43869851pln.151.1537522928828; Fri, 21 Sep 2018 02:42:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537522928; cv=none; d=google.com; s=arc-20160816; b=wXtmZpd90H0pBWXZBsCtbBRO2BDAJWy6r239owaKQuhKF24LrUghhaLOQyLHCBW95y 7j/lOQHhZmIKvCoN1wxUAuLdDRsb9u3TmU3ggMoAi3sik/LJuZJm3v3SDlJL1Gt1tVig QkHW1eSOzzzZ07+xWeBZacqoeo1R0Hqj/NfFi8b0qjfS/tGmigNwPVoVvy97nvDmY5z/ DecDwh4Uyioh6Xzd6PXlXTiWtbYB9dV8FjPxUedfPikM0dYbmqj8jZW/sxTUL2fUzZgZ 5BdonsWZ8MVEo2Z/xY5TzTmRIrY0bT0fX8K6dKtK9XzE8CQJAjGeWO1dr2+fiD8kaC+w 56/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=T/e+JLEKXTgSfDPKht4kCvBN8RwpoT+LB7uPFcrHTw8=; b=bNL3gY6MEeRdjwoZWGGpes8iTqowgwhajYGuU6Oli8zPZchrOTLAXOG4FSRmLUpfVt 9tSREhqIBexoe01lEw88AV/Fw+xQu5/1icnl99JtOlkGPk0Ofoo0XoyJuc1nr1q8kGaP qAlDO+t6MPL7kLRlnpmXIHXZldLGONzDYzKNba9gZOhKwUR+Wl7DBCYr6oJgJkt/Mb+m vS0jQQKy1d1Hpe+VqZpqgeFK6usLNkzCbz8U6CqBqtoAnAp0voGnOr3JWQc9hdkTnjqL CDiwYTO4rBN5IbXJP/AJg0x0APsANmFfQV/hhDXXjl0BsVNhzFzRGGpBJLTiDdqqXaXN 4FaA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b28-v6si26808363pfe.265.2018.09.21.02.41.51; Fri, 21 Sep 2018 02:42:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389618AbeIUP2U (ORCPT + 99 others); Fri, 21 Sep 2018 11:28:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47818 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389022AbeIUP2T (ORCPT ); Fri, 21 Sep 2018 11:28:19 -0400 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 136573002C77; Fri, 21 Sep 2018 09:40:18 +0000 (UTC) Received: from gondolin (dhcp-192-222.str.redhat.com [10.33.192.222]) by smtp.corp.redhat.com (Postfix) with ESMTP id 72B58106A78C; Fri, 21 Sep 2018 09:40:11 +0000 (UTC) Date: Fri, 21 Sep 2018 11:40:09 +0200 From: Cornelia Huck To: Tony Krowiak Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, freude@de.ibm.com, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, borntraeger@de.ibm.com, kwankhede@nvidia.com, bjsdjshi@linux.vnet.ibm.com, pbonzini@redhat.com, alex.williamson@redhat.com, pmorel@linux.vnet.ibm.com, alifm@linux.vnet.ibm.com, mjrosato@linux.vnet.ibm.com, jjherne@linux.vnet.ibm.com, thuth@redhat.com, pasic@linux.vnet.ibm.com, berrange@redhat.com, fiuczy@linux.vnet.ibm.com, buendgen@de.ibm.com, frankja@linux.ibm.com, Tony Krowiak Subject: Re: [PATCH v10 06/26] s390: vfio-ap: sysfs interfaces to configure adapters Message-ID: <20180921114009.24e928d9.cohuck@redhat.com> In-Reply-To: <1536781396-13601-7-git-send-email-akrowiak@linux.vnet.ibm.com> References: <1536781396-13601-1-git-send-email-akrowiak@linux.vnet.ibm.com> <1536781396-13601-7-git-send-email-akrowiak@linux.vnet.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.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Fri, 21 Sep 2018 09:40:18 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 12 Sep 2018 15:42:56 -0400 Tony Krowiak wrote: > From: Tony Krowiak > > Introduces two new sysfs attributes for the VFIO mediated > matrix device for assigning AP adapters to and unassigning > AP adapters from a mediated matrix device. The IDs of the > AP adapters assigned to the mediated matrix device will be > stored in an AP mask (APM). > > The bits in the APM, from most significant to least significant > bit, correspond to AP adapter IDs (APID) 0 to 255. On > some systems, the maximum allowable adapter number may be less > than 255 - depending upon the host's AP configuration - and > assignment may be rejected if the input adapter ID exceeds the > limit. > > When an adapter is assigned, the bit corresponding to the APID > will be set in the APM. Likewise, when an adapter is > unassigned, the bit corresponding to the APID will be cleared > from the APM. > > In order to successfully assign an adapter, the APQNs derived from > the adapter ID being assigned and the queue indexes of all domains > previously assigned: > > 1. Must be bound to the vfio_ap device driver. > > 2. Must not be assigned to any other mediated matrix device > > If there are no domains assigned to the mdev, then there must > be an AP queue bound to the vfio_ap device driver with an > APQN containing the APID, otherwise all domains > subsequently assigned will fail because there will be no > AP queues bound with an APQN containing the adapter ID. > > Assigning or un-assigning an AP adapter will be rejected if > a guest using the mediated matrix device is running. > > The relevant sysfs structures are: > > /sys/devices/vfio_ap/matrix/ > ...... [mdev_supported_types] > ......... [vfio_ap-passthrough] > ............ [devices] > ...............[$uuid] > .................. assign_adapter > .................. unassign_adapter > > To assign an adapter to the $uuid mediated matrix device's APM, > write the APID to the assign_adapter file. To unassign an adapter, > write the APID to the unassign_adapter file. The APID is specified > using conventional semantics: If it begins with 0x the number will > be parsed as a hexadecimal number; if it begins with a 0 the number > will be parsed as an octal number; otherwise, it will be parsed as a > decimal number. > > For example, to assign adapter 173 (0xad) to the mediated matrix > device $uuid: > > echo 173 > assign_adapter > > or > > echo 0xad > assign_adapter > > or > > echo 0255 > assign_adapter > > To unassign adapter 173 (0xad): > > echo 173 > unassign_adapter > > or > > echo 0xad > unassign_adapter > > or > > echo 0255 > unassign_adapter > > Signed-off-by: Tony Krowiak > Reviewed-by: Halil Pasic > Tested-by: Michael Mueller > Tested-by: Farhan Ali > Tested-by: Pierre Morel > Signed-off-by: Christian Borntraeger > --- > drivers/s390/crypto/vfio_ap_ops.c | 295 +++++++++++++++++++++++++++++++++++++ > 1 files changed, 295 insertions(+), 0 deletions(-) (...) > +/** > + * vfio_ap_mdev_verify_no_sharing > + * > + * Verifies that the APQNs derived from the cross product of the AP adapter IDs > + * and AP queue indexes comprising the AP matrix are not configured for another > + * mediated device. AP queue sharing is not allowed. > + * > + * @kvm: the KVM guest > + * @matrix: the AP matrix > + * > + * Returns 0 if the APQNs are not shared, otherwise; returns -EADDRINUSE. > + */ > +static int vfio_ap_mdev_verify_no_sharing(struct ap_matrix_mdev *matrix_mdev) > +{ > + int nbits; > + struct ap_matrix_mdev *lstdev; > + unsigned long apm[BITS_TO_LONGS(matrix_mdev->matrix.apm_max + 1)]; > + unsigned long aqm[BITS_TO_LONGS(matrix_mdev->matrix.aqm_max + 1)]; Can you please convert this to use a fixed-size array? I think {apm,aqm}_max has an upper bound of 255? (Also, this can use DECLARE_BITMAP.) > + > + list_for_each_entry(lstdev, &matrix_dev->mdev_list, node) { > + if (matrix_mdev == lstdev) > + continue; > + > + memset(apm, 0, sizeof(apm)); > + memset(aqm, 0, sizeof(aqm)); > + > + /* > + * We work on full longs, as we can only exclude the leftover > + * bits in non-inverse order. The leftover is all zeros. > + */ > + nbits = sizeof(apm) * BITS_PER_BYTE; > + if (!bitmap_and(apm, matrix_mdev->matrix.apm, > + lstdev->matrix.apm, nbits)) > + continue; > + > + nbits = sizeof(aqm) * BITS_PER_BYTE; > + if (!bitmap_and(aqm, matrix_mdev->matrix.aqm, > + lstdev->matrix.aqm, nbits)) > + continue; > + > + return -EADDRINUSE; > + } > + > + return 0; > +}