Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp873033ybb; Wed, 8 Apr 2020 11:32:46 -0700 (PDT) X-Google-Smtp-Source: APiQypKvlZCGMH4nsYIlR52KzhaSGBjWuAoyCLoqEQ1W42fxvfS2VryxbsS8fk+5JJDhCAIcrRiY X-Received: by 2002:a4a:558f:: with SMTP id e137mr3350711oob.89.1586370766833; Wed, 08 Apr 2020 11:32:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586370766; cv=none; d=google.com; s=arc-20160816; b=vlmbiJQA9D1FDj7GuRDhe/tTYaeiBPIYZCMI8MjvtNQkn1nuTl1m2CnOa1qWr72ZwP jbNfGPOO1fMTG7fm+dv5ZKSZSBcSpqw+9u3Vgc5Q4tGkIou8CRIcIuONTjceNg6ITfAh yNRk+m0Tn+Z4Wv6DAkwiBbb4gTO53MH5Uhf2SJubMhnrq+KmMj/BjHgXREAECdi+mE3Z +YUSu5nRANUxnX3P49G716z9VPKaBjLn+HoW9Oia2R9/CBc2yEah8/RlC2T/VAI3ZuEe lcPeU3CWvjFHrdTo2xmqEWD+ODCVNfK703EPt/Txpt235WonQUZlVGqYRf905xT7D6iY ZcMg== 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:dkim-signature; bh=OS1BYKCP7cBLf4oxAp06CiLumissixgN9CzFoFmvPFs=; b=co9hCA09Jzql1bo2fgMHSlX+zJAizAPJ1TkvLb70pskmH1HpIVLGOI3FKwNg4mEKGt L4/XU09f04Jh5dQO0XCvcDp7dgHPdzefK7FuEIrPRfg3SENEhU9fcgN+D7IZahV6sHLT K+/oH+YWLwuRh/fgD/7cWrahmp/yXbs37cnAibvIUDL489ELN+npXpAodKk1D7KZOjYe yOUSNtS0QTKQoxccGvpBTjppE2DbI4Iv7L1JJFipNKNv4c+kaPSgaP93yaqFC6dib4ZO ytsRtQ2iM+BRJhnAnNOwt/+BL0AmP9vAtXYvO3AO7Zcr+YojbxPDVr/RW3/rCKy1FcaN T73A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=g1fuDWN0; 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=pass (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 n5si2937114oof.46.2020.04.08.11.32.32; Wed, 08 Apr 2020 11:32:46 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=g1fuDWN0; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729320AbgDHQqX (ORCPT + 99 others); Wed, 8 Apr 2020 12:46:23 -0400 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:46959 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728872AbgDHQqX (ORCPT ); Wed, 8 Apr 2020 12:46:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586364381; 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=OS1BYKCP7cBLf4oxAp06CiLumissixgN9CzFoFmvPFs=; b=g1fuDWN0gcw1sfLsyfBwPDsk2d0+OV8McPVZy1Mpta29aEKQXVDDo9203W8IyHSCt7F60c NfE2amgG38QUj9i4aJTkkhaIec8yl5uv+1q/RDFcyqgaW/4mwdGdbZft9ZGGiKRENlMdzs AaatgXkmg2xc0ZVSnVsyvVloSe+t69c= 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-22-q_lr7LQCNHOKfs94-AlDmw-1; Wed, 08 Apr 2020 12:46:19 -0400 X-MC-Unique: q_lr7LQCNHOKfs94-AlDmw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2AAA5801E5A; Wed, 8 Apr 2020 16:46:18 +0000 (UTC) Received: from gondolin (ovpn-113-103.ams2.redhat.com [10.36.113.103]) by smtp.corp.redhat.com (Postfix) with ESMTP id 908721195A4; Wed, 8 Apr 2020 16:46:09 +0000 (UTC) Date: Wed, 8 Apr 2020 18:46:06 +0200 From: Cornelia Huck To: Tony Krowiak Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, freude@linux.ibm.com, borntraeger@de.ibm.com, mjrosato@linux.ibm.com, pmorel@linux.ibm.com, pasic@linux.ibm.com, alex.williamson@redhat.com, kwankhede@nvidia.com, jjherne@linux.ibm.com, fiuczy@linux.ibm.com Subject: Re: [PATCH v7 06/15] s390/vfio-ap: sysfs attribute to display the guest CRYCB Message-ID: <20200408184606.309d9cd9.cohuck@redhat.com> In-Reply-To: <60c6bfb6-dd0a-75dc-1043-8dffe983220a@linux.ibm.com> References: <20200407192015.19887-1-akrowiak@linux.ibm.com> <20200407192015.19887-7-akrowiak@linux.ibm.com> <20200408123344.1a9032e1.cohuck@redhat.com> <60c6bfb6-dd0a-75dc-1043-8dffe983220a@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.11 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 8 Apr 2020 12:38:49 -0400 Tony Krowiak wrote: > On 4/8/20 6:33 AM, Cornelia Huck wrote: > > On Tue, 7 Apr 2020 15:20:06 -0400 > > Tony Krowiak wrote: > > > >> The matrix of adapters and domains configured in a guest's CRYCB may > >> differ from the matrix of adapters and domains assigned to the matrix mdev, > >> so this patch introduces a sysfs attribute to display the CRYCB of a guest > >> using the matrix mdev. For a matrix mdev denoted by $uuid, the crycb for a > >> guest using the matrix mdev can be displayed as follows: > >> > >> cat /sys/devices/vfio_ap/matrix/$uuid/guest_matrix > >> > >> If a guest is not using the matrix mdev at the time the crycb is displayed, > >> an error (ENODEV) will be returned. > >> > >> Signed-off-by: Tony Krowiak > >> --- > >> drivers/s390/crypto/vfio_ap_ops.c | 58 +++++++++++++++++++++++++++++++ > >> 1 file changed, 58 insertions(+) > >> +static DEVICE_ATTR_RO(guest_matrix); > > Hm... should information like the guest configuration be readable by > > everyone? Or should it be restricted a bit more? > > Why? The matrix attribute already displays the APQNs of the queues > assigned to the matrix mdev. The guest_matrix attribute merely displays > a subset of the matrix (i.e., the APQNs assigned to the mdev that reference > queue devices bound to the vfio_ap device driver). > > How can this be restricted? I was thinking of using e.g. 400 instead of 444 for the permissions. I'm not sure if the info about what subset of the queues the guest actually uses is all that interesting (except for managing guests); but if I see guest information being exposed, I get a little wary, so I just stumbled over this. Maybe I'll come back to that once I have looked at the series in more detail, but this might not be a problem at all. > > > > >> + > >> static struct attribute *vfio_ap_mdev_attrs[] = { > >> &dev_attr_assign_adapter.attr, > >> &dev_attr_unassign_adapter.attr, > >> @@ -1050,6 +1107,7 @@ static struct attribute *vfio_ap_mdev_attrs[] = { > >> &dev_attr_unassign_control_domain.attr, > >> &dev_attr_control_domains.attr, > >> &dev_attr_matrix.attr, > >> + &dev_attr_guest_matrix.attr, > >> NULL, > >> }; > >> >