Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp5316491pxv; Wed, 7 Jul 2021 00:28:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxLMJ8DpfF5c+/LuYGIdd+1tTaNlGdM8i25oFSwWHnqMnUnI9pRnRx3jmiPMTShDgrUuhA4 X-Received: by 2002:a17:906:974f:: with SMTP id o15mr12465700ejy.476.1625642919020; Wed, 07 Jul 2021 00:28:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625642919; cv=none; d=google.com; s=arc-20160816; b=S7qRC3+Zsk/twl1Lz/H82OnWeYVTKYwjF11smvKctllrB3IXs0mdHw/TIrgdi6J4eP bgBTI9UEaQ6OpuCuJwDG7913NVGy9z1hVn4VJRljfb0VXy62Iht//jfmFrduHXKb+6HF LSYqZOfv42YUIP5BJ4Sedh/gvAbgB4XJXzpCQUjeylyHlqDBZv6y2Sn4GKr5L/8qqbpR OfLMXLCaRiqffsYHZf22j6GrOUBLKy5mLr09WDZc2/o/7l5bDl3s2n4f1GiD8prglFhq uSwJtmRVEyI794sa7U4oK5tTxPWASmclJ68z4oBd/Vdev3Ns4H4ErdGLnuAkvu1P9SMx V8BQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:dkim-signature; bh=uGQVNsdhqGpbhjnmA9wt9C+nuF+WZ2jtK2PCyQyMaTw=; b=DBDuntEAecjlwdQ95YsWO3YRpf8VC1rZ2i9cOWTsbJ87TmBNOONFQy4L6EfAg6UOwk yGMQ79ik4vU+WE9jObA7gWyika5cnm/G9guDK8zyRZN+Nct0oE3NK+ysgPCkfFjgTLQn q/FgEnpIdjaMSw7xJrPAmjv0sBOzXtvnLhXTaHNsW2qFePiEzfRD3Hz14WxS1TeGlC// 5+SYsbktQIr9emA2H+tnCpHVGC/Sqfc2jWYONrrUHyXNu/lHIVpCdPZSCh/EZRRHf26a CuC3A8dKuXbv+sU5EhqbMGaWaHQKBgqaORbflKHstw6mDmwrRKuJLs/ICiF1NzU0CwZE zyuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dZ+h8Yrc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z13si17977465edq.483.2021.07.07.00.28.14; Wed, 07 Jul 2021 00:28:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dZ+h8Yrc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230312AbhGGH3l (ORCPT + 99 others); Wed, 7 Jul 2021 03:29:41 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:33304 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230327AbhGGH3k (ORCPT ); Wed, 7 Jul 2021 03:29:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1625642820; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uGQVNsdhqGpbhjnmA9wt9C+nuF+WZ2jtK2PCyQyMaTw=; b=dZ+h8Yrc0nuwtsI+sQGsb4uOwiiuohe1uU5AVE0Jm7rSuITt0z4cfUczFnSGx//Jg/3kRP H4cladGi5CTNeP1pdzKnR6aSIt6kfIZLBewtjtTiTgb9RmV0n/eAcr7sEhPo9kTgs6hnD4 XEZ8tA2p1u+Lgh8W5DO0dWt70uqziF8= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-569-Ay6T7YXUNtiTaKKqzZu0Nw-1; Wed, 07 Jul 2021 03:26:59 -0400 X-MC-Unique: Ay6T7YXUNtiTaKKqzZu0Nw-1 Received: by mail-wm1-f72.google.com with SMTP id k5-20020a7bc3050000b02901e081f69d80so361666wmj.8 for ; Wed, 07 Jul 2021 00:26:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=uGQVNsdhqGpbhjnmA9wt9C+nuF+WZ2jtK2PCyQyMaTw=; b=jSEfmxRVBy/ecVIPHEShO+lTJULij0yzHGpyl9r9ywMb/tcumIUww/a1JbTHfC7MAV yXIOMLgAbudy27xaoWCq9aJGmIvPotxdVve4mR4HRvxYx6FkyQdc3QahL8uEJxHU4qVA gJGZMJlT0uAaYca4SXihy5OWzGXy9YcHYa1CflTXZRjfx6vEhwBgIIivu598jZn+V7Mw /hA40x2X/JSDDGXYldko0ZNil1xUNdBemwenwkTwDaSvYAN3i0kwrmRtmcURgowrqgyH 6evjCz600FMb+nL2M06nvCZjbaJ8TfRII69tXyhdewVuFmbohVO3tKJu9hmbs8TryWSA 8Qlw== X-Gm-Message-State: AOAM530gvDyPfurHiJWvn5nruiV6YWbNnulmVZuncMHgK7tL2+FWdipF aMbuu7jnaQOOx7Wtw7VVE9K76YVRgzX/COA16NTGZ4MxciT2nOT8NEk/O6JYNtsa/SbuqrkwKkL aj5f/5/htoEb0lJPn70ECd2HC40YOoAc5JDyrJJKCNpX5tVKTe89IVloaeKTqR0pMnIeQDusH X-Received: by 2002:a5d:4e43:: with SMTP id r3mr26182448wrt.132.1625642817976; Wed, 07 Jul 2021 00:26:57 -0700 (PDT) X-Received: by 2002:a5d:4e43:: with SMTP id r3mr26182419wrt.132.1625642817687; Wed, 07 Jul 2021 00:26:57 -0700 (PDT) Received: from [192.168.3.132] (p4ff23579.dip0.t-ipconnect.de. [79.242.53.121]) by smtp.gmail.com with ESMTPSA id 12sm5657418wme.28.2021.07.07.00.26.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jul 2021 00:26:57 -0700 (PDT) Subject: Re: [PATCH] KVM: s390: Enable specification exception interpretation To: Janis Schoetterl-Glausch , Christian Borntraeger , Cornelia Huck , Janis Schoetterl-Glausch , Janosch Frank , Heiko Carstens , Vasily Gorbik Cc: Claudio Imbrenda , "open list:KERNEL VIRTUAL MACHINE for s390 (KVM/s390)" , "open list:S390" , open list References: <20210706114714.3936825-1-scgl@linux.ibm.com> <87k0m3hd7h.fsf@redhat.com> <194128c1-8886-5b8b-2249-5ec58b8e7adb@de.ibm.com> <45690e80-5c7c-1e11-99d5-c0d1482755ad@de.ibm.com> <8318ce18-65ea-8b4d-4df1-9f9ba79f2bb7@linux.vnet.ibm.com> From: David Hildenbrand Organization: Red Hat Message-ID: Date: Wed, 7 Jul 2021 09:26:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <8318ce18-65ea-8b4d-4df1-9f9ba79f2bb7@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06.07.21 17:27, Janis Schoetterl-Glausch wrote: > On 7/6/21 5:16 PM, David Hildenbrand wrote: >> On 06.07.21 14:02, Christian Borntraeger wrote: >>> >>> >>> On 06.07.21 13:59, David Hildenbrand wrote: >>>> On 06.07.21 13:56, Christian Borntraeger wrote: >>>>> >>>>> >>>>> On 06.07.21 13:52, Cornelia Huck wrote: >>>>>> On Tue, Jul 06 2021, Janis Schoetterl-Glausch wrote: >>>>>> >>>>>>> When this feature is enabled the hardware is free to interpret >>>>>>> specification exceptions generated by the guest, instead of causing >>>>>>> program interruption interceptions. >>>>>>> >>>>>>> This benefits (test) programs that generate a lot of specification >>>>>>> exceptions (roughly 4x increase in exceptions/sec). >>>>>>> >>>>>>> Interceptions will occur as before if ICTL_PINT is set, >>>>>>> i.e. if guest debug is enabled. >>>>>>> >>>>>>> Signed-off-by: Janis Schoetterl-Glausch >>>>>>> --- >>>>>>> I'll additionally send kvm-unit-tests for testing this feature. >>>>>>> >>>>>>>     arch/s390/include/asm/kvm_host.h | 1 + >>>>>>>     arch/s390/kvm/kvm-s390.c         | 2 ++ >>>>>>>     arch/s390/kvm/vsie.c             | 2 ++ >>>>>>>     3 files changed, 5 insertions(+) >>>>>> >>>>>> (...) >>>>>> >>>>>>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c >>>>>>> index b655a7d82bf0..aadd589a3755 100644 >>>>>>> --- a/arch/s390/kvm/kvm-s390.c >>>>>>> +++ b/arch/s390/kvm/kvm-s390.c >>>>>>> @@ -3200,6 +3200,8 @@ static int kvm_s390_vcpu_setup(struct kvm_vcpu *vcpu) >>>>>>>             vcpu->arch.sie_block->ecb |= ECB_SRSI; >>>>>>>         if (test_kvm_facility(vcpu->kvm, 73)) >>>>>>>             vcpu->arch.sie_block->ecb |= ECB_TE; >>>>>>> +    if (!kvm_is_ucontrol(vcpu->kvm)) >>>>>>> +        vcpu->arch.sie_block->ecb |= ECB_SPECI; >>>>>> >>>>>> Does this exist for any hardware version (i.e. not guarded by a cpu >>>>>> feature?) >>>>> >>>>> Not for all hardware versions, but also no indication. The architecture >>>>> says that the HW is free to do this or not. (which makes the vsie code >>>>> simpler). >>>> >>>> I remember the architecture said at some point to never set undefined bits - and this bit is undefined on older HW generations. I might be wrong, though. >>> >>> I can confirm that this bit will be ignored on older machines. The notion of >>> never setting undefined bits comes from "you never know what this bit will >>> change in future machines". Now we know :-) >> >> Well, okay then :) >> >> So the plan for vSIE is to always keep it disabled? IIUC, one could similarly always forward the bit of set. > > The bit does get copied for vSIE. ... and I missed that hunk :) LGTM then Reviewed-by: David Hildenbrand -- Thanks, David / dhildenb