Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4256688imm; Fri, 18 May 2018 01:57:20 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpqMBrjzDIpqsWedG6IgKjShCo8CxkMLzd2Kt1laDg8VZApE+9qDaz8B+fJ5NkvJbPYwjc9 X-Received: by 2002:a17:902:524:: with SMTP id 33-v6mr8766170plf.25.1526633840516; Fri, 18 May 2018 01:57:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526633840; cv=none; d=google.com; s=arc-20160816; b=l7l1zsYVgTWTtG73HHvyT9WfPAUokAFIun7udaXrj0tY1vry4Yyd+bv33VPmvd2na9 2KOBeSBqDVcXHUhpMYIX69QaaqXJIUJ7qeEEIDXJYT7aCr+D6axLqru3Mm/MHzjk/v1R E8fWH8rn218w4TS3jD8iF7JtzVFY9+q1jBn5XU69/VsnKzjxjn5+OfqfjbkBEcMkHbaj DHBQyd9zqXWuejF308f14KsaxP6pXKq+zULl1mIL4PAEgj/DXASFqVNHhOFAFTEGgnvd Otw2Dv19RllXRUSBYk+dHLtimlLr+157y7/agQhZYmdwc2mOQJLvkyeOviIy1SvdIlsg /RQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :from:references:cc:to:subject:reply-to:arc-authentication-results; bh=qpr72lT2dGn7ddy6Nnil9wo+GKBObrHc0tvfVOXh7eY=; b=lccUuxUam0aMpb6DCzEvgPHyIR2XfFy1v0AUVjK2DI1tTGic29nQE1uv09KRLSRLEY dybhG2OXp6Q8yxZ8ONozLqixRogC2lOjVPSAY+YKGFULiIvHiRIXB0R0k95Vc6KDiWnI M45m0o1OJNr2FJ6JosHpBchhSZPJ3WWVgq0epo5WQDDPCEWhX21YX5RvuKvgBkFyjo0r wWjzzHDae+/ZC99GCpIetOWltRAQICC27EDOdpTIXVBcuQri+Ms9K3MW3HJW7FxrVkgv 54T98Dzwkg0ehVvETQ47WKlvXR5CuvgoqqAAOMXzS74VVBE6IhopPebRx6mmPmQGhCNf hblg== 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=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j7-v6si7053624pfj.267.2018.05.18.01.57.05; Fri, 18 May 2018 01:57:20 -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=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753457AbeERIzt (ORCPT + 99 others); Fri, 18 May 2018 04:55:49 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:60710 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751888AbeERIzp (ORCPT ); Fri, 18 May 2018 04:55:45 -0400 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4I8sePx025797 for ; Fri, 18 May 2018 04:55:44 -0400 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0a-001b2d01.pphosted.com with ESMTP id 2j1qk7hkfs-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 18 May 2018 04:55:44 -0400 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 18 May 2018 09:55:42 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 18 May 2018 09:55:37 +0100 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w4I8taqo58196034; Fri, 18 May 2018 08:55:36 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C0CF6A404D; Fri, 18 May 2018 09:47:03 +0100 (BST) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1B5D5A4040; Fri, 18 May 2018 09:47:03 +0100 (BST) Received: from [9.152.224.33] (unknown [9.152.224.33]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 18 May 2018 09:47:03 +0100 (BST) Reply-To: pmorel@linux.ibm.com Subject: Re: [PATCH v5 06/13] KVM: s390: interfaces to manage guest's AP matrix To: Tony Krowiak , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: freude@de.ibm.com, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, borntraeger@de.ibm.com, cohuck@redhat.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 References: <1525705912-12815-1-git-send-email-akrowiak@linux.vnet.ibm.com> <1525705912-12815-7-git-send-email-akrowiak@linux.vnet.ibm.com> <13331f80-8821-6de3-ca29-7a3ea869e4f1@linux.vnet.ibm.com> <1891f565-284f-ab30-ebc7-8fef85b5fba7@linux.ibm.com> From: Pierre Morel Date: Fri, 18 May 2018 10:55:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-TM-AS-GCONF: 00 x-cbid: 18051808-0012-0000-0000-000005D7ED35 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18051808-0013-0000-0000-000019551E03 Message-Id: <2ae0b04a-f091-6c06-dc07-b6fa265b484a@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-18_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805180099 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16/05/2018 15:48, Tony Krowiak wrote: > On 05/16/2018 09:15 AM, Pierre Morel wrote: >> On 16/05/2018 15:12, Tony Krowiak wrote: >>> On 05/16/2018 03:48 AM, Pierre Morel wrote: >>>> On 15/05/2018 18:07, Tony Krowiak wrote: >>>>> On 05/15/2018 10:55 AM, Pierre Morel wrote: >>>>>> On 07/05/2018 17:11, Tony Krowiak wrote: >>>>>>> Provides interfaces to manage the AP adapters, usage domains >>>>>>> and control domains assigned to a KVM guest. >>>>>>> >>>>>>> The guest's SIE state description has a satellite structure >>>>>>> called the >>>>>>> Crypto Control Block (CRYCB) containing three bitmask fields >>>>>>> identifying the adapters, queues (domains) and control domains >>>>>>> assigned to the KVM guest: >>>>>>> >>>> ...snip... >>>>>>> +} >>>>>> >>>>>> This function (ap_validate_queue_sharing) only verifies that VM >>>>>> don't share queues. >>>>>> What about the queues used by a host application? >>>>> >>>>> How can that be verified from this function? I suppose I could put >>>>> a check in here to >>>>> verify that the queues are reserved by the vfio_ap device driver, >>>>> but that would >>>>> be redundant because an AP queue can not be assigned to a mediated >>>>> matrix device >>>>> via its sysfs attributes unless it is reserved by the vfio_ap >>>>> device driver (see >>>>> patches 7, 8 and 9). >>>>> >>>>>> >>>>>> >>>>>> I understand that you want to implement  these checks within KVM >>>>>> but this is >>>>>> related to which queue devices are bound to the matrix and which >>>>>> one are not. >>>>> >>>>> See my comments above and below about AP queue assignment to the >>>>> mediated matrix >>>>> device. The one verification we can't do when the devices are >>>>> assigned is whether >>>>> another guest is using the queue because assignment occurs before >>>>> the guest using >>>>> the queue is started in which case we have no access to KVM. It >>>>> makes no sense to >>>>> do so at assignment time anyway because it doesn't matter until >>>>> the guest using >>>>> the mediated matrix device is started, so that check is done in KVM. >>>>> >>>>>> >>>>>> >>>>>> I think that this should be related somehow to the bounded queue >>>>>> devices and >>>>>> therefor implemented inside the matrix driver. >>>>> >>>>> As I stated above, when an AP queue is assigned to the mediated >>>>> matrix device via >>>>> its sysfs attributes, a check is done to verify that it is bound >>>>> to the vfio_ap >>>>> device driver (see patches 7, 8 and 9). If not, then assignment >>>>> will be rejected; >>>>> therefore, it will not be possible to configure a CRYCB with AP >>>>> queues that are >>>>> not bound to the device driver. >>>> >>>> This patch and te followed patches take care that the queues are >>>> bound to the >>>> matrix driver when they are assigned to the matrix using the sysfs >>>> entries. >>>> >>>> But they do not take care that the queue can not be unbound before >>>> you start >>>> the guest, and they are not in the path if the admin decide to >>>> unbind a queue >>>> at some later time. >>> >>> That is a good point. I need to put a check in the device driver at >>> the time >>> the mediated device fd is opened to verify that the queues being >>> configured in >>> the guest's CRYCB are bound to the driver. >> >> not only, you also need to avoid the possibility of unbinding the >> device. >> For this you need to use the remove callback from the driver. > > I thought I addressed this already. The definition of the remove > callback does > not specify a return value, so there is currently no way to prevent > the AP bus > from removing the queue device on unbind. I sent an email to Harald to > discuss > adding a return value to the callback. If you can not prevent the unbinding you must remove the according bits in the matrix. > >> >> >>> >>>> >>>> >>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Pierre >>>>>> >>>>> >>>> >>> >> > -- Pierre Morel Linux/KVM/QEMU in Böblingen - Germany