Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp246750yba; Fri, 12 Apr 2019 02:45:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqwdynOiYCR2f/lNfkBYHGczUUdye8vwimSHYP7sWuform7+zrfeDaGTvS/D9miQMDboY8g/ X-Received: by 2002:a17:902:141:: with SMTP id 59mr19994209plb.132.1555062339806; Fri, 12 Apr 2019 02:45:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555062339; cv=none; d=google.com; s=arc-20160816; b=1FujMcGaxjaW7EIkkn+wO2qFRJEh/TlnGkFcmvM2bLEDqWDg6cMfry/ODdMC4fTsk3 PPKiTNz3it/W0yZgbcwIZEQjYFeu34Iwf6oz47x2TT3aj4JtCeBHLesbjB9RCWoFYG0P CzYF9o+n2PUivHUctw4bYH6IUytIwJRM+Rmg+yQe7Q3UkZOS09FBPnSjofzp62CaGgQW erLhNx8QWbjRz/u5MVCHWbK4/V1uzd31LBVnwudYzTbYf0/bpxrFxbSw61aWhisWBIi/ erPJNFgcCy2q1D6kkHBzKiCMMkK49JQI3OkrQu86VFcgF/i9O1lqF4z6AO572IQvwoWT cjpA== 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=6yBPr9AA0efX+Dg/eRQZRoNZpswc/hJS/3TaUU1kZVU=; b=arCDaRYNB6PPx2n8+eTKBgpMub6v5OquYzDB1E02QuSYABW3d6Q7AKQ8qE6Jzct6kb t1Veq+4yqEXpMbhN6dir9Tsq51XytEvMPZxy//QQL+dLF4SymgHHpHrbgZoLKeChoiW5 wtLCBglIqSmhFswdF8I1Z8KTzU6Cnys+Atv2ap4c8SjgiaQbfYsNuQy4z930G80XVYgY VmDTHRH7QvaqqWC9bfOQoXMz3ieknN6DjciYIOrciLR/XU32g0+tpIl20AGukGcoY/lf T3Bpp2AQQloivqj0IBp7lhpnIZJmhLtghYupUp9b5EJJD8ZmcyIy+F8hT27bh5gENvdH rWhw== 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 k123si16412710pfc.285.2019.04.12.02.45.23; Fri, 12 Apr 2019 02:45:39 -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 S1726826AbfDLJnW (ORCPT + 99 others); Fri, 12 Apr 2019 05:43:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40386 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726742AbfDLJnW (ORCPT ); Fri, 12 Apr 2019 05:43:22 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1CD6599CE2; Fri, 12 Apr 2019 09:43:22 +0000 (UTC) Received: from gondolin (dhcp-192-187.str.redhat.com [10.33.192.187]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8212E1778B; Fri, 12 Apr 2019 09:43:15 +0000 (UTC) Date: Fri, 12 Apr 2019 11:43:13 +0200 From: Cornelia Huck To: Tony Krowiak Cc: Harald Freudenberger , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Reinhard Buendgen , borntraeger@de.ibm.com, frankja@linux.ibm.com, david@redhat.com, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, pmorel@linux.ibm.com, pasic@linux.ibm.com, alex.williamson@redhat.com, kwankhede@nvidia.com Subject: Re: [PATCH 1/7] s390: zcrypt: driver callback to indicate resource in use Message-ID: <20190412114313.0156c01b.cohuck@redhat.com> In-Reply-To: <223c82c7-6a75-7209-3652-c2341c83878f@linux.ibm.com> References: <1555016604-2008-1-git-send-email-akrowiak@linux.ibm.com> <1555016604-2008-2-git-send-email-akrowiak@linux.ibm.com> <223c82c7-6a75-7209-3652-c2341c83878f@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.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 12 Apr 2019 09:43:22 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 12 Apr 2019 08:54:54 +0200 Harald Freudenberger wrote: > On 11.04.19 23:03, Tony Krowiak wrote: > > Introduces a new driver callback to prevent a root user from unbinding > > an AP queue from its device driver if the queue is in use. This prevents > > a root user from inadvertently taking a queue away from a guest and > > giving it to the host, or vice versa. The callback will be invoked > > whenever a change to the AP bus's apmask or aqmask sysfs interfaces may > > result in one or more AP queues being removed from its driver. If the > > callback responds in the affirmative for any driver queried, the change > > to the apmask or aqmask will be rejected with a device in use error. > > > > For this patch, only non-default drivers will be queried. Currently, > > there is only one non-default driver, the vfio_ap device driver. The > > vfio_ap device driver manages AP queues passed through to one or more > > guests and we don't want to unexpectedly take AP resources away from > > guests which are most likely independently administered. > > > > Signed-off-by: Tony Krowiak > > Hello Tony > > you are going out with your patches but ... what is the result of the discussions > we had in the past ? Do we have a common understanding that we want to have > it this way ? A driver which is able to claim resources and the bus code > has lower precedence ? I don't know about previous discussions, but I'm curious how you arrived at this design. A driver being able to override the bus code seems odd. Restricting this to 'non-default' drivers looks even more odd. What is this trying to solve? Traditionally, root has been able to shoot any appendages of their choice. I would rather expect that in a supported setup you'd have some management software keeping track of device usage and making sure that only unused queues can be unbound. Do we need to export more information to user space so that management software can make better choices? > > > --- > > drivers/s390/crypto/ap_bus.c | 138 +++++++++++++++++++++++++++++++++++++++++-- > > drivers/s390/crypto/ap_bus.h | 3 + > > 2 files changed, 135 insertions(+), 6 deletions(-)