From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753474AbeERIzt (ORCPT ); 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 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 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