Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1988083imm; Wed, 16 May 2018 06:16:38 -0700 (PDT) X-Google-Smtp-Source: AB8JxZp7kODukET/Nv51Jvkh2bbmfKkcthJGlpvskQPbkt4DPOLJDi0ZUXMINLgb1eRTSBq5TFG1 X-Received: by 2002:a17:902:9303:: with SMTP id bc3-v6mr960719plb.18.1526476598255; Wed, 16 May 2018 06:16:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526476598; cv=none; d=google.com; s=arc-20160816; b=UOPztjSYJ5tNAQ2v251WFeoagOkbluJ9WSsBioKLkDfZ71b8KOtiNwJaXGVC+qJk/B TkrLnYFcWbDdXLFvUfHmDWijBhm5AyT9X9OCqdP17EfNmYa3bgIh46cN5Oas1X6M0m9A xvf6HvFqSQ1cKwAPTPGgAwecAzSvuFhz368/7FKD1CHmzMhsAGibIsTsmEq57G80G9Ly RnrmwWrKrwOlxPW2hfDz+gwN0qk/v3q4LDnXfSE/J8RR7FLv27+X19B67mR2Pysaovvy gjQopyU86Fh3DW2x+9zOBGuOC1QVAoHApw8pMvKcQjvhpTYDm68ubaqXZN0vVSWncq0D 9GQg== 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=/LjGg/NTU8Ouc8JgXck7jTGZf62h7DUsfyevy14HMgQ=; b=koo/tSRxJrRTTIsVQ4XMq7/T+cfc0fkAWofufRrRpjQKoVlNkubbtu7qOuRvymM4Ro cmGFCqES8FOHoybybirWnq3eXH1ejAzYB6ZtGb6/+lx3Ss5PGdMEinp1TUM537EDQdid EI3ywLjUT6CauuhPX8N/Jyd5ga3sOF3X2DVmaodT9UeNj3jeJPamq042JtmkkxtniNJX NE4UjGg+hHRpup/h+uSXa6yEYpGY/F3tQCeGiiiEZh+M7/ttRpPgsZrQJU3QZl+kcFVr vVo/tCdMxSAKDaKesq3HnXUX6a2GvqEMzB+wBlbmPqtj4eI3fK9GxCHwJ3v68UkYyMkE 8tow== 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 g6-v6si2102288pgs.396.2018.05.16.06.16.22; Wed, 16 May 2018 06:16:38 -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 S1752699AbeEPNPt (ORCPT + 99 others); Wed, 16 May 2018 09:15:49 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:60628 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752539AbeEPNPq (ORCPT ); Wed, 16 May 2018 09:15:46 -0400 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4GDEEbs122947 for ; Wed, 16 May 2018 09:15:46 -0400 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0a-001b2d01.pphosted.com with ESMTP id 2j0kcxx1m2-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 16 May 2018 09:15:45 -0400 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 16 May 2018 14:15:41 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 16 May 2018 14:15:38 +0100 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w4GDFbxT66781328; Wed, 16 May 2018 13:15:37 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 825B0AE045; Wed, 16 May 2018 14:04:57 +0100 (BST) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D1FE6AE051; Wed, 16 May 2018 14:04:56 +0100 (BST) Received: from [9.152.224.33] (unknown [9.152.224.33]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 16 May 2018 14:04:56 +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> From: Pierre Morel Date: Wed, 16 May 2018 15:15:36 +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: <13331f80-8821-6de3-ca29-7a3ea869e4f1@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-TM-AS-GCONF: 00 x-cbid: 18051613-0020-0000-0000-0000041DD20D X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18051613-0021-0000-0000-000042B2EEBD Message-Id: <1891f565-284f-ab30-ebc7-8fef85b5fba7@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-16_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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805160136 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > >> >> >>> >>>> >>>> >>>> Regards, >>>> >>>> Pierre >>>> >>> >> > -- Pierre Morel Linux/KVM/QEMU in Böblingen - Germany