Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp171419imm; Mon, 2 Jul 2018 09:30:03 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcspyUB/9awEPFEYpVCISAi7IvVy4BGTWfxLot3AL8c70QFsF1NhDFi/GBl4NZO50Re9y7K X-Received: by 2002:a63:5a5e:: with SMTP id k30-v6mr7724907pgm.123.1530549003828; Mon, 02 Jul 2018 09:30:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530549003; cv=none; d=google.com; s=arc-20160816; b=KYd6AAweCy32K1DUSZZJ5PCGv8JwJXJttevNvDZs1nlEv0N031e7gpM239U/DdIupU 56jR9SvshBe1ekgzROURB6NfBVPrGSyu3vBpk5mcwZ+BKWI6bLCN8Hrcqcf/1G1BvMAI I7LRRKMCgEWEdqY9C2/8p+wH/IybR9La6Jq3Z6LZOcBgxwjK5Pe7qbAlfSjCdHqmu5fk VB73taJXjBMaFYFqnozrLiau74iKJPC8dFpzDJhQ2G5LrGCl3t0rGsq26rXW+92L5zG2 3q3tyacN/KidF+KUekgfFZg/m7TH/0SBXwurUgYz70Gxyyidm+zV62k8GI6GgK99GxW3 jRwQ== 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:arc-authentication-results; bh=kUsJIx+iOe0NfL94yuVkoQ9lldw3+t9g8Ktmtv/Ef9s=; b=wfOiJ3yANsvT/bL6KoPjRT9ZMEVzYVt7yXemnRp38nGTUkxVw8RrwdkJ63EBwa/QuX 9i4RAtRxq4PXYisnYBIm3TKgCd91b0s1+Hg50rs/hF1Q17DSGsgvvOShA++2xDtXCx0G mM7MfxbAYBrdMmrW8LDip5fMH6hdE/ySAWtcjgfk+XBltjq5BC70uL+7MBVzHe/FX/Yq ZdwRsG+4xksEvl9DUrGMh5sGl/t36D7SOBI2ubXeYr+uYdIM6e4+8diXoqLSRprGZh9G os5hgWU6M/lS/SFchOQBbrkg+s3i0e5TOGr2fmlVHZ6cyK62LqqL54t0O+McUlsNyFoI VTXQ== 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 a10-v6si15868185pff.304.2018.07.02.09.29.49; Mon, 02 Jul 2018 09:30:03 -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 S1752775AbeGBQ2x (ORCPT + 99 others); Mon, 2 Jul 2018 12:28:53 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:59756 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752728AbeGBQ2t (ORCPT ); Mon, 2 Jul 2018 12:28:49 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EBC2240250FF; Mon, 2 Jul 2018 16:28:48 +0000 (UTC) Received: from gondolin (ovpn-117-51.ams2.redhat.com [10.36.117.51]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3168D2166B5D; Mon, 2 Jul 2018 16:28:44 +0000 (UTC) Date: Mon, 2 Jul 2018 18:28:40 +0200 From: Cornelia Huck To: Halil Pasic Cc: Tony Krowiak , Christian Borntraeger , Tony Krowiak , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, freude@de.ibm.com, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.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 Subject: Re: [PATCH v6 05/21] KVM: s390: CPU model support for AP virtualization Message-ID: <20180702182840.34560fed.cohuck@redhat.com> In-Reply-To: <76165cca-b8ec-172a-4a1b-6f3514b44344@linux.ibm.com> References: <1530306683-7270-1-git-send-email-akrowiak@linux.vnet.ibm.com> <1530306683-7270-6-git-send-email-akrowiak@linux.vnet.ibm.com> <276b5ae7-7f27-faae-1e5a-0d4c084139e9@linux.ibm.com> <20180702174103.5d1ce603.cohuck@redhat.com> <20180702181108.2c721a86.cohuck@redhat.com> <76165cca-b8ec-172a-4a1b-6f3514b44344@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.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 02 Jul 2018 16:28:49 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 02 Jul 2018 16:28:49 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'cohuck@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2 Jul 2018 18:20:55 +0200 Halil Pasic wrote: > On 07/02/2018 06:11 PM, Cornelia Huck wrote: > > On Mon, 2 Jul 2018 11:54:28 -0400 > > Tony Krowiak wrote: > > > >> On 07/02/2018 11:41 AM, Cornelia Huck wrote: > >>> On Mon, 2 Jul 2018 11:37:11 -0400 > >>> Tony Krowiak wrote: > >>> > >>>> On 07/02/2018 10:38 AM, Christian Borntraeger wrote: > >>>>> On 06/29/2018 11:11 PM, Tony Krowiak wrote: > >>>>>> Introduces a new CPU model feature and two CPU model > >>>>>> facilities to support AP virtualization for KVM guests. > >>>>>> > >>>>>> CPU model feature: > >>>>>> > >>>>>> The KVM_S390_VM_CPU_FEAT_AP feature indicates that > >>>>>> AP instructions are available on the guest. This > >>>>>> feature will be enabled by the kernel only if the AP > >>>>>> instructions are installed on the linux host. This feature > >>>>>> must be specifically turned on for the KVM guest from > >>>>>> userspace to use the VFIO AP device driver for guest > >>>>>> access to AP devices. > >>>>>> > >>>>>> CPU model facilities: > >>>>>> > >>>>>> 1. AP Query Configuration Information (QCI) facility is installed. > >>>>>> > >>>>>> This is indicated by setting facilities bit 12 for > >>>>>> the guest. The kernel will not enable this facility > >>>>>> for the guest if it is not set on the host. This facility > >>>>>> must not be set by userspace if the KVM_S390_VM_CPU_FEAT_AP > >>>>>> feature is not installed. > >>>>>> > >>>>>> If this facility is not set for the KVM guest, then only > >>>>>> APQNs with an APQI less than 16 will be available to the > >>>>>> guest regardless of the guest's matrix configuration. This > >>>>>> is a limitation of the AP bus running on the guest. > >>>>>> > >>>>>> 2. AP Facilities Test facility (APFT) is installed. > >>>>>> > >>>>>> This is indicated by setting facilities bit 15 for > >>>>>> the guest. The kernel will not enable this facility for > >>>>>> the guest if it is not set on the host. This facility > >>>>>> must not be set by userspace if the KVM_S390_VM_CPU_FEAT_AP > >>>>>> feature is not installed. > >>>>>> > >>>>>> If this facility is not set for the KVM guest, then no > >>>>>> AP devices will be available to the guest regardless of > >>>>>> the guest's matrix configuration. This is a limitation > >>>>>> of the AP bus running under the guest. > >>>>>> > >>>>>> Reviewed-by: Christian Borntraeger > >>>>>> Reviewed-by: Halil Pasic > >>>>>> Signed-off-by: Tony Krowiak > >>>>> I think it probably should be at the end of the series, other than that its good. > >>>> If I move this to the end of the series, the very next patch checks the > >>>> > >>>> KVM_S390_VM_CPU_FEAT_AP feature? > >>> Introduce it here, offer it only with the last patch? > >> > >> I apologize, but I don't know what you mean by this. Are you suggesting > >> this patch > >> should only include the #define for KVM_S390_VM_CPU_FEAT_AP? > > > > Yes, just introduce the definition here (so code later in the series > > can refer to it) and flip the switch (offer the bit) as the final > > patch. > > > > The other features introduced and exposed here are no different. For > KVM_S390_VM_CPU_FEAT_AP defer exposing means defer allow_cpu_feat(); > for the STFLE features, defer adding to FACILITIES_KVM_CPUMODEL. > > Anyway, I think the definition should be squashed into #6. Expose the > features after patch #6 is in place or expose them at the end of the > series is IMHO a matter of taste -- and I lean towards expose at the > end of the series. Squashing with patch 6 and enabling at the end of the series sounds good to me as well.