Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp789611imm; Tue, 15 May 2018 09:11:53 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo13YBzv65Yl1bSXcEw6Wxsb/HX51L3mzPl3BxDtik/z4QRvIvEXpVVJMDMJtZrcpk5qk8O X-Received: by 2002:aa7:8305:: with SMTP id t5-v6mr15729953pfm.198.1526400713195; Tue, 15 May 2018 09:11:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526400713; cv=none; d=google.com; s=arc-20160816; b=1La5VFLrRQd65Rbyl7Dily7nSvw/cWi4NrrWwjcBjwb/VHzD891Zkhv/esy7lSqLci MweCSsg+XQ7lQoSLFd7/xa7acmVo+AvBebBftYqqdFkP0PC4ZCKSf/qA+XF/uYfYD/AI l3UF2UqaxHLtEPWUpxta3PDWr7p1rmu1Ozco0jr2HEsDz6FN5xUOsD9r1QLHxhLvv/m+ OYHybQlktGWamMQSArIMnf0FrhlfcZJXW4ahEvvFGRU2lpmJ9af6YdyFSxsCHKXtfkFf mzn26Gw0uAh9y2gCdYVxgnswcmUwP/kgB6Exah9h3eiVymUSC7Z+/T0AkULxL5BQoFPf I1qg== 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:arc-authentication-results; bh=aiz0/LuiZgRvwe9Z+bsS4Dv4Fu0BoW8AkT9P8Abid18=; b=ihxF61peiCdELjdGmyRubluuzC4XM0xhXgYqB2fFprrEcG33fkK+BBC+XMFVL9S4RD NNayIFSd7vO6rr74e2iKdrdxr5prK+Xt+ughmcA2vwVzYR9hkPzLSd4h92wUU6dXGu89 GoL/ripQ1XvzEw18P7n3QnARFViD97doJ7+gTEnovpQM+qu9v6LlYHBcTCA6jW0SDDWf AMacp4E8jnEEFHGWDSgnoUNYOFQF2yXoEKn2cOHo8OSygkHZgi8UtT/SxRVcHHuGOftD Lk/35u7Wse8nsEwE6FSUQgZRv9+uatDdErv12l46LD3r8B9Cqh9wx4iLa2xmRMW242id VakQ== 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 r3-v6si327589pli.324.2018.05.15.09.11.38; Tue, 15 May 2018 09:11:53 -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 S1754032AbeEOQIu (ORCPT + 99 others); Tue, 15 May 2018 12:08:50 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:47998 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753744AbeEOQH7 (ORCPT ); Tue, 15 May 2018 12:07:59 -0400 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4FG6F65017594 for ; Tue, 15 May 2018 12:07:59 -0400 Received: from e15.ny.us.ibm.com (e15.ny.us.ibm.com [129.33.205.205]) by mx0a-001b2d01.pphosted.com with ESMTP id 2j008610pj-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 15 May 2018 12:07:58 -0400 Received: from localhost by e15.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 15 May 2018 12:07:57 -0400 Received: from b01cxnp22033.gho.pok.ibm.com (9.57.198.23) by e15.ny.us.ibm.com (146.89.104.202) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 15 May 2018 12:07:54 -0400 Received: from b01ledav002.gho.pok.ibm.com (b01ledav002.gho.pok.ibm.com [9.57.199.107]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w4FG7rQj44302386; Tue, 15 May 2018 16:07:53 GMT Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 93EE112405B; Tue, 15 May 2018 13:09:48 -0400 (EDT) Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CCF8B124052; Tue, 15 May 2018 13:09:47 -0400 (EDT) Received: from oc8043147753.ibm.com (unknown [9.60.75.218]) by b01ledav002.gho.pok.ibm.com (Postfix) with ESMTP; Tue, 15 May 2018 13:09:47 -0400 (EDT) Subject: Re: [PATCH v5 06/13] KVM: s390: interfaces to manage guest's AP matrix To: pmorel@linux.ibm.com, 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> From: Tony Krowiak Date: Tue, 15 May 2018 12:07:52 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-TM-AS-GCONF: 00 x-cbid: 18051516-0036-0000-0000-000002F52637 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00009030; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000260; SDB=6.01032715; UDB=6.00527983; IPR=6.00811846; MB=3.00021128; MTD=3.00000008; XFM=3.00000015; UTC=2018-05-15 16:07:57 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18051516-0037-0000-0000-000044582530 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-15_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-1805150162 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: >> >> * The AP Adapter Mask (APM) field identifies the AP adapters assigned to >> the KVM guest >> >> * The AP Queue Mask (AQM) field identifies the AP queues assigned to >> the KVM guest. Each AP queue is connected to a usage domain within >> an AP adapter. >> >> * The AP Domain Mask (ADM) field identifies the control domains >> assigned to the KVM guest. >> >> Each adapter, queue (usage domain) and control domain are identified by >> a number from 0 to 255. The bits in each mask, from most significant to >> least significant bit, correspond to the numbers 0-255. When a bit is >> set, the corresponding adapter, queue (usage domain) or control domain >> is assigned to the KVM guest. >> >> This patch will set the bits in the APM, AQM and ADM fields of the >> CRYCB referenced by the KVM guest's SIE state description. The process >> used is: >> >> 1. Verify that the bits to be set do not exceed the maximum bit >> number for the given mask. >> >> 2. Verify that the APQNs that can be derived from the cross product >> of the bits set in the APM and AQM fields of the KVM guest's CRYCB >> are not assigned to any other KVM guest running on the same linux >> host. >> >> 3. Set the APM, AQM and ADM in the CRYCB according to the matrix >> configured for the mediated matrix device via its sysfs >> assign_adapter, assign_domain and assign_control domain attribute >> files respectively. >> >> Signed-off-by: Tony Krowiak >> --- >> arch/s390/include/asm/kvm-ap.h | 52 ++++++++++++ >> arch/s390/include/asm/kvm_host.h | 1 + >> arch/s390/kvm/kvm-ap.c | 161 >> ++++++++++++++++++++++++++++++++++++++ >> 3 files changed, 214 insertions(+), 0 deletions(-) >> >> diff --git a/arch/s390/include/asm/kvm-ap.h >> b/arch/s390/include/asm/kvm-ap.h >> index 6af1ff8..21fe9f2 100644 >> --- a/arch/s390/include/asm/kvm-ap.h >> +++ b/arch/s390/include/asm/kvm-ap.h >> @@ -12,8 +12,33 @@ >> >> #include >> #include >> +#include >> #include >> >> +#define KVM_AP_MASK_BYTES(n) DIV_ROUND_UP(n, BITS_PER_BYTE) >> + >> +/** >> + * The AP matrix is comprised of three bit masks identifying the >> adapters, >> + * queues (domains) and control domains that belong to an AP matrix. >> The bits in >> + * each mask, from least significant to most significant bit, >> correspond to IDs >> + * 0 to 255. When a bit is set, the corresponding ID belongs to the >> matrix. >> + * >> + * @apm identifies the AP adapters in the matrix >> + * @apm_max: max adapter number in @apm >> + * @aqm identifies the AP queues (domains) in the matrix >> + * @aqm_max: max domain number in @aqm >> + * @adm identifies the AP control domains in the matrix >> + * @adm_max: max domain number in @adm >> + */ >> +struct kvm_ap_matrix { >> + unsigned long apm_max; >> + DECLARE_BITMAP(apm, 256); >> + unsigned long aqm_max; >> + DECLARE_BITMAP(aqm, 256); >> + unsigned long adm_max; >> + DECLARE_BITMAP(adm, 256); > > Just a possible performance impact: > you may have interest to put all bitmaps first to take adventage > of quadword handling (If bitmaps use it) and put unsigned longs > at the end. The DECLARE_BITMAP macros declare the first operand as an array of unsigned long, so each of the fields falls on a natural alignment boundary which I believe means the structure or any of its fields require only one memory access. I don't see how use of this structure will cause performance impacts. Even if that were the case, the impact would be negligible and completely unnoticeable by a human IMHO. I prefer to keep the related fields together. > > >> +}; >> + >> /** >> * kvm_ap_apxa_installed >> * >> @@ -57,4 +82,31 @@ >> */ >> bool kvm_ap_instructions_available(void); >> >> +/** >> + * kvm_ap_configure_matrix >> + * >> + * Configure the AP matrix for a KVM guest. >> + * >> + * @kvm: the KVM guest >> + * @matrix: the matrix configuration information >> + * >> + * Returns 0 if: >> + * 1. The AP instructions are installed on the guest >> + * 2. The APQNs derived from the intersection of the set of adapter >> + * IDs (APM) and queue indexes (AQM) in @matrix are not >> configured for >> + * any other KVM guest running on the same linux host. >> + * Otherwise returns an error code. >> + */ >> +int kvm_ap_configure_matrix(struct kvm *kvm, struct kvm_ap_matrix >> *matrix); >> + >> +/** >> + * kvm_ap_deconfigure_matrix >> + * >> + * Deconfigure the AP matrix for a KVM guest. Clears all of the bits >> in the >> + * APM, AQM and ADM in the guest's CRYCB. >> + * >> + * @kvm: the KVM guest >> + */ >> +void kvm_ap_deconfigure_matrix(struct kvm *kvm); >> + >> #endif /* _ASM_KVM_AP */ >> diff --git a/arch/s390/include/asm/kvm_host.h >> b/arch/s390/include/asm/kvm_host.h >> index ef4b237..8736cde 100644 >> --- a/arch/s390/include/asm/kvm_host.h >> +++ b/arch/s390/include/asm/kvm_host.h >> @@ -257,6 +257,7 @@ struct kvm_s390_sie_block { >> __u64 tecmc; /* 0x00e8 */ >> __u8 reservedf0[12]; /* 0x00f0 */ >> #define CRYCB_FORMAT_MASK 0x00000003 >> +#define CRYCB_FORMAT0 0x00000000 >> #define CRYCB_FORMAT1 0x00000001 >> #define CRYCB_FORMAT2 0x00000003 >> __u32 crycbd; /* 0x00fc */ >> diff --git a/arch/s390/kvm/kvm-ap.c b/arch/s390/kvm/kvm-ap.c >> index 00bcfb0..98b53c7 100644 >> --- a/arch/s390/kvm/kvm-ap.c >> +++ b/arch/s390/kvm/kvm-ap.c >> @@ -7,6 +7,7 @@ >> * Author(s): Tony Krowiak >> */ >> #include >> +#include >> #include >> >> #include "kvm-s390.h" >> @@ -81,3 +82,163 @@ int kvm_ap_apxa_installed(void) >> return 0; >> } >> EXPORT_SYMBOL(kvm_ap_apxa_installed); >> + >> +static inline void kvm_ap_clear_crycb_masks(struct kvm *kvm) >> +{ >> + memset(&kvm->arch.crypto.crycb->apcb0, 0, >> + sizeof(kvm->arch.crypto.crycb->apcb0)); > > Here you prefer to set both structure to 0 instead of testing which > structure to erase. The function performs the task described by its name ... it clears the CRYCB masks (plural). This function will most likely be called only once when the CRYCB masks are configured. I see no good reason to change this. > > >> + memset(&kvm->arch.crypto.crycb->apcb1, 0, >> + sizeof(kvm->arch.crypto.crycb->apcb1)); >> +} >> + > > ...snip... > >> +/** >> + * kvm_ap_validate_queue_sharing >> + * >> + * Verifies that the APQNs derived from the cross product of the AP >> adapter IDs >> + * and AP queue indexes comprising the AP matrix are not configured for >> + * another guest. AP queue sharing is not allowed. >> + * >> + * @kvm: the KVM guest >> + * @matrix: the AP matrix >> + * >> + * Returns 0 if the APQNs are valid, otherwise; returns -EBUSY. >> + */ >> +static int kvm_ap_validate_queue_sharing(struct kvm *kvm, >> + struct kvm_ap_matrix *matrix) >> +{ >> + struct kvm *vm; >> + unsigned long *apm, *aqm; >> + unsigned long apid, apqi; >> + >> + >> + /* No other VM may share an AP Queue with the input VM */ >> + list_for_each_entry(vm, &vm_list, vm_list) { >> + if (kvm == vm) >> + continue; >> + >> + apm = kvm_ap_get_crycb_apm(vm); >> + if (!bitmap_and(apm, apm, matrix->apm, matrix->apm_max + 1)) >> + continue; >> + >> + aqm = kvm_ap_get_crycb_aqm(vm); >> + if (!bitmap_and(aqm, aqm, matrix->aqm, matrix->aqm_max + 1)) >> + continue; >> + >> + for_each_set_bit_inv(apid, apm, matrix->apm_max + 1) >> + for_each_set_bit_inv(apqi, aqm, matrix->aqm_max + 1) >> + kvm_ap_log_sharing_err(vm, apid, apqi); >> + >> + return -EBUSY; >> + } >> + >> + return 0; >> +} > > 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. > > > Regards, > > Pierre >