Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp531954imm; Wed, 22 Aug 2018 08:18:04 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzeIgxReqJcqeHpDqU/gguwL79SWjrhH/6gpLOxs5MGq08l0eXaVRDx/P1vVf5mfUpvceZ5 X-Received: by 2002:a63:e60c:: with SMTP id g12-v6mr52466967pgh.308.1534951084487; Wed, 22 Aug 2018 08:18:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534951084; cv=none; d=google.com; s=arc-20160816; b=G8DHcRDT+6UesWHpsJSHwuFTN9yY0zhyAFMQ5z0sh2r0rTEzRnDkdMWmKbRNacNcto xrxAdcd4f9ZFu2uTEKFI37PP8XYp+687js9XvM3wxXZi3x0fmhrvhC9QUZKwnQLtpukU aJrClo620UL/ArcnP2Bkl07lHKcB0A+cZiUQr4EChmLYO1BMqwD+RNy+j9/9hkrvr0Bx oWM8c3S93RuI7KJCNibpyLu/0OZzNmkODNIS2rZiTzx1NNCg9CvMCHiRmtsmQ7yb0cZs 15K83/98mUbd1LsegICks6lF0T4KqQfRg/TzTC1NyrS+CuIDJqhw8/0EBNkFTdBMRBvW nDjw== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:autocrypt:openpgp:from:references:cc:to :subject:arc-authentication-results; bh=+PbrMNYrLu/79YsBuZzyjxj1xDxK+rAtslIE0YAnrBE=; b=LteuPDpQwujv81PfXBghOdq7OHb826rMK4IFOdctwkgSKNn5MvwSUuELqD9+vJn/xV F27DGdOBmmvSUBjBB10Th/7Pl3Y8c5bSQ5Hu7vvKercy55q68Dgg3fZpvO3Rj7SOtw3a s0XEmTJPLMWEzLd7aytVJG39KK6KYsA5caO+0A+Mgx0hLLBUPbfljlFHjEdwhVvqAciB nllir3BkTWWMIxnyZGs2ovsd9u/COTRoneNQV+ewPCaUz5i5Fv73FWJCWU+hOoc5N5Si JXvXgsjAw62RInQQpTH0vbH2SKHFUYxrLIEiCy4aoVq60IRn6Gw4FskkJaK/1033KuQb V/7g== 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 t22-v6si1854014pgj.546.2018.08.22.08.17.49; Wed, 22 Aug 2018 08:18:04 -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 S1729371AbeHVSaJ (ORCPT + 99 others); Wed, 22 Aug 2018 14:30:09 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:37740 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728343AbeHVSaI (ORCPT ); Wed, 22 Aug 2018 14:30:08 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 04B7B4023820; Wed, 22 Aug 2018 15:04:52 +0000 (UTC) Received: from [10.36.117.196] (ovpn-117-196.ams2.redhat.com [10.36.117.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id B9F9BA9E86; Wed, 22 Aug 2018 15:04:45 +0000 (UTC) Subject: Re: [PATCH v9 21/22] KVM: s390: CPU model support for AP virtualization To: pmorel@linux.ibm.com, 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, frankja@linux.ibm.com, Tony Krowiak References: <1534196899-16987-1-git-send-email-akrowiak@linux.vnet.ibm.com> <1534196899-16987-22-git-send-email-akrowiak@linux.vnet.ibm.com> <2c2c4859-ed3e-a492-dd59-78529c7768b2@redhat.com> From: David Hildenbrand Openpgp: preference=signencrypt Autocrypt: addr=david@redhat.com; prefer-encrypt=mutual; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwX4EEwECACgFAljj9eoCGwMFCQlmAYAGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEE3eEPcA/4Na5IIP/3T/FIQMxIfNzZshIq687qgG 8UbspuE/YSUDdv7r5szYTK6KPTlqN8NAcSfheywbuYD9A4ZeSBWD3/NAVUdrCaRP2IvFyELj xoMvfJccbq45BxzgEspg/bVahNbyuBpLBVjVWwRtFCUEXkyazksSv8pdTMAs9IucChvFmmq3 jJ2vlaz9lYt/lxN246fIVceckPMiUveimngvXZw21VOAhfQ+/sofXF8JCFv2mFcBDoa7eYob s0FLpmqFaeNRHAlzMWgSsP80qx5nWWEvRLdKWi533N2vC/EyunN3HcBwVrXH4hxRBMco3jvM m8VKLKao9wKj82qSivUnkPIwsAGNPdFoPbgghCQiBjBe6A75Z2xHFrzo7t1jg7nQfIyNC7ez MZBJ59sqA9EDMEJPlLNIeJmqslXPjmMFnE7Mby/+335WJYDulsRybN+W5rLT5aMvhC6x6POK z55fMNKrMASCzBJum2Fwjf/VnuGRYkhKCqqZ8gJ3OvmR50tInDV2jZ1DQgc3i550T5JDpToh dPBxZocIhzg+MBSRDXcJmHOx/7nQm3iQ6iLuwmXsRC6f5FbFefk9EjuTKcLMvBsEx+2DEx0E UnmJ4hVg7u1PQ+2Oy+Lh/opK/BDiqlQ8Pz2jiXv5xkECvr/3Sv59hlOCZMOaiLTTjtOIU7Tq 7ut6OL64oAq+zsFNBFXLn5EBEADn1959INH2cwYJv0tsxf5MUCghCj/CA/lc/LMthqQ773ga uB9mN+F1rE9cyyXb6jyOGn+GUjMbnq1o121Vm0+neKHUCBtHyseBfDXHA6m4B3mUTWo13nid 0e4AM71r0DS8+KYh6zvweLX/LL5kQS9GQeT+QNroXcC1NzWbitts6TZ+IrPOwT1hfB4WNC+X 2n4AzDqp3+ILiVST2DT4VBc11Gz6jijpC/KI5Al8ZDhRwG47LUiuQmt3yqrmN63V9wzaPhC+ xbwIsNZlLUvuRnmBPkTJwwrFRZvwu5GPHNndBjVpAfaSTOfppyKBTccu2AXJXWAE1Xjh6GOC 8mlFjZwLxWFqdPHR1n2aPVgoiTLk34LR/bXO+e0GpzFXT7enwyvFFFyAS0Nk1q/7EChPcbRb hJqEBpRNZemxmg55zC3GLvgLKd5A09MOM2BrMea+l0FUR+PuTenh2YmnmLRTro6eZ/qYwWkC u8FFIw4pT0OUDMyLgi+GI1aMpVogTZJ70FgV0pUAlpmrzk/bLbRkF3TwgucpyPtcpmQtTkWS gDS50QG9DR/1As3LLLcNkwJBZzBG6PWbvcOyrwMQUF1nl4SSPV0LLH63+BrrHasfJzxKXzqg rW28CTAE2x8qi7e/6M/+XXhrsMYG+uaViM7n2je3qKe7ofum3s4vq7oFCPsOgwARAQABwsFl BBgBAgAPBQJVy5+RAhsMBQkJZgGAAAoJEE3eEPcA/4NagOsP/jPoIBb/iXVbM+fmSHOjEshl KMwEl/m5iLj3iHnHPVLBUWrXPdS7iQijJA/VLxjnFknhaS60hkUNWexDMxVVP/6lbOrs4bDZ NEWDMktAeqJaFtxackPszlcpRVkAs6Msn9tu8hlvB517pyUgvuD7ZS9gGOMmYwFQDyytpepo YApVV00P0u3AaE0Cj/o71STqGJKZxcVhPaZ+LR+UCBZOyKfEyq+ZN311VpOJZ1IvTExf+S/5 lqnciDtbO3I4Wq0ArLX1gs1q1XlXLaVaA3yVqeC8E7kOchDNinD3hJS4OX0e1gdsx/e6COvy qNg5aL5n0Kl4fcVqM0LdIhsubVs4eiNCa5XMSYpXmVi3HAuFyg9dN+x8thSwI836FoMASwOl C7tHsTjnSGufB+D7F7ZBT61BffNBBIm1KdMxcxqLUVXpBQHHlGkbwI+3Ye+nE6HmZH7IwLwV W+Ajl7oYF+jeKaH4DZFtgLYGLtZ1LDwKPjX7VAsa4Yx7S5+EBAaZGxK510MjIx6SGrZWBrrV TEvdV00F2MnQoeXKzD7O4WFbL55hhyGgfWTHwZ457iN9SgYi1JLPqWkZB0JRXIEtjd4JEQcx +8Umfre0Xt4713VxMygW0PnQt5aSQdMD58jHFxTk092mU+yIHj5LeYgvwSgZN4airXk5yRXl SE+xAvmumFBY Organization: Red Hat GmbH Message-ID: Date: Wed, 22 Aug 2018 17:04:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 22 Aug 2018 15:04:52 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 22 Aug 2018 15:04:52 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'david@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22.08.2018 16:33, Pierre Morel wrote: > On 22/08/2018 13:19, David Hildenbrand wrote: >> On 13.08.2018 23:48, Tony Krowiak wrote: >>> From: Tony Krowiak >>> >>> 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. >>> >>> If this facility is not set for the KVM guest, then only >>> APQNs with an APQI less than 16 will be used by a Linux >>> guest regardless of the matrix configuration for the virtual >>> machine. This is a limitation of the Linux AP bus. >>> >>> 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. >>> >>> 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 for the virtual >>> machine. This is a limitation of the Linux AP bus. >>> >>> Signed-off-by: Tony Krowiak >>> Reviewed-by: Christian Borntraeger >>> Reviewed-by: Halil Pasic >>> Tested-by: Michael Mueller >>> Tested-by: Farhan Ali >>> Signed-off-by: Christian Borntraeger >>> --- >>> arch/s390/kvm/kvm-s390.c | 5 +++++ >>> arch/s390/tools/gen_facilities.c | 2 ++ >>> 2 files changed, 7 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c >>> index 1e8cb67..d5e04d2 100644 >>> --- a/arch/s390/kvm/kvm-s390.c >>> +++ b/arch/s390/kvm/kvm-s390.c >>> @@ -367,6 +367,11 @@ static void kvm_s390_cpu_feat_init(void) >>> >>> if (MACHINE_HAS_ESOP) >>> allow_cpu_feat(KVM_S390_VM_CPU_FEAT_ESOP); >>> + >>> + /* Check if AP instructions installed on host */ >>> + if (ap_instructions_available()) >>> + allow_cpu_feat(KVM_S390_VM_CPU_FEAT_AP); >>> + >>> /* >>> * We need SIE support, ESOP (PROT_READ protection for gmap_shadow), >>> * 64bit SCAO (SCA passthrough) and IDTE (for gmap_shadow unshadowing). >>> diff --git a/arch/s390/tools/gen_facilities.c b/arch/s390/tools/gen_facilities.c >>> index 90a8c9e..a52290b 100644 >>> --- a/arch/s390/tools/gen_facilities.c >>> +++ b/arch/s390/tools/gen_facilities.c >>> @@ -106,6 +106,8 @@ struct facility_def { >>> >>> .name = "FACILITIES_KVM_CPUMODEL", >>> .bits = (int[]){ >>> + 12, /* AP Query Configuration Information */ >>> + 15, /* AP Facilities Test */ >>> -1 /* END */ >>> } >>> }, >>> >> >> I really wonder if we should also export the APXA facility. >> >> We can probe and allow that CPU feature. However, we cannot disable it >> (as of now). >> >> We have other CPU features where it is the same case (basically all >> subfunctions). See kvm_s390_get_processor_subfunc(). We probe them and >> export them, but support to disable them has never been implemented. >> >> On a high level, we could then e.g. deny to start a QEMU guest if APXA >> is available but has been disabled. (until we know that disabling it >> actually works - if ever). >> >> This helps to catch nasty migration bugs (e.g. APXA suddenly >> disappearing). Although unlikely, definitely possible. > >> >> Are there any other AP related facilities that the guest can from now on >> probe that should also become part of the CPU model? >> > > > > Before going too far in a discussion on features which we do not really > need, we can make clear that we only support beginning with z13 and only > in the Z architecture mode as host and as guest. Easy answer: The CPU model should be prepared for all eventualities. We have handled it that way since the beginning. The minimal thing I expect to have is all relevant features probed and exported to user space. Just like we do with all the MSA/PTFF/PLO subfunctions. I expect (and remember) this to be the same for PQAP. (there are some very special cases regarding subfunctions that are not indicated) Why? The CPU model is not KVM specific. > > We then need to abort the VFIO driver if APXA is not installed. While you should do that, the CPU model is more generic. This would only imply that as of now, the APXA feature would always be available if the AP feature is available. In addition, it makes the vSIE handling code easier - there is always APXA and for now it cannot be disabled. > > In this case we will have no problem with older guests not having idea > about APXA. > > Would it be a solution? Any feature the guest sees, should be part of the CPU model. The whole environment for cpu subfunctions is already in place both in KVM and QEMU. Only disabling subfunctions in KVM is not implemented yet. You can exclude any subfunctions/facilities that are only valid on LPAR level and cannot be used in some guest either way. (that makes life sometimes easier) I know that this might sound a little bit complicated, but it really isn't. Boils down to modifying kvm_s390_cpu_feat_init() and specifying some features+feature groups in QEMU. > > > Regards, > Pierre > -- Thanks, David / dhildenb