Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp649196pxb; Thu, 25 Feb 2021 11:19:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJybl6b+xRdTpqgsc0loVD0/qU2TSXSa91mevcpPcK9E54VEA+YpBvxF1smf71/fCw7qnAbq X-Received: by 2002:a17:906:948c:: with SMTP id t12mr3975900ejx.259.1614280783224; Thu, 25 Feb 2021 11:19:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614280783; cv=none; d=google.com; s=arc-20160816; b=VcHNf104L0gwD5ViCd9NA8cAMgxFaSedW+5EoyYzU/41Fx57/CnmGOHIZnC9GiD2y1 PzzBz6OynRl2XAHMY86oBbKFtnnHvSipGSwcieOiguaZiBgaWC1yhorjNO/ohalczA/I Trr8LlcXErlODyO4VaXXr24zBB5B6AHgjkfcdna17WCIwCQpen5mBvdX8rjx7V5DKMz2 axdTcjpEiOImsiX8eHeLLmv79hHM5ak9LSwtu7E83I3LM1akTJbaEBoe3mb9eMXVqpt4 5REoMtu6J5UH0M60RSBM9Mt5F4mtgkNGO4/owDviLnOiXiLvMlBsZLOoneQZKRRTP/32 BM5w== 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:subject :organization:from:references:cc:to:dkim-signature; bh=06Wk8j084czweIl2sAHUw6QfIrOuQIVq2H1D3mFdUrw=; b=o9SQs5OcIbHNbg7MZMSGgVzoStwyxZ0csBwskwusNShckJJdASMIiv/Qv3u0rCs3cL noTGYFs4PkPBrt1fKg6AW8Jq6ehZO7OuPr1sYDxFE+ONs81LTEJ+SKE/hr5xBtGfTp4E Q8DdT67/gZKxefZMSrhUQqE0QSlWis9AD1P3bdDBY5WzLKAOFd1DjkWyfCHnQFv3GdWL tv8dCVrcX5bnFdut+zFRluu5XjURjYWHQMhsF2zwX8LlQ3go7glz19fBz4J9YRFR36/X sQjAmGC0uKFA3THvPsNrkT+jIg8Dv9JewSLk63DC61NLRAb5P3vzYgTy0AtXF+3WX3Ca GspQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=innT8Sjb; 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 a17si4092542edu.207.2021.02.25.11.19.20; Thu, 25 Feb 2021 11:19:43 -0800 (PST) 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=innT8Sjb; 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 S234738AbhBYTSH (ORCPT + 99 others); Thu, 25 Feb 2021 14:18:07 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:33901 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234538AbhBYTOH (ORCPT ); Thu, 25 Feb 2021 14:14:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614280359; 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=06Wk8j084czweIl2sAHUw6QfIrOuQIVq2H1D3mFdUrw=; b=innT8SjbUgQlVZVDBXqwti84HaJ6AEwk2xlI4e/+rmiBysi+IC4LTHFgUvbiU6J5Wv+TAO YZ1tVwGf0Wg/lbq9qmSPULjcHVgZwgjvpKYt0cZwUNudk3n+fr7yxvwM0BzMa+1Ob0FuzX omJZXu/nSrpO2pvJYO6JpiscvQ5X8lE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-212-FRsNhabSOcWl8_2jz3Lyag-1; Thu, 25 Feb 2021 14:12:36 -0500 X-MC-Unique: FRsNhabSOcWl8_2jz3Lyag-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DD79A107ACF3; Thu, 25 Feb 2021 19:12:34 +0000 (UTC) Received: from [10.36.114.58] (ovpn-114-58.ams2.redhat.com [10.36.114.58]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1B7585D9D2; Thu, 25 Feb 2021 19:12:32 +0000 (UTC) To: Claudio Imbrenda , linux-kernel@vger.kernel.org Cc: borntraeger@de.ibm.com, frankja@linux.ibm.com, cohuck@redhat.com, kvm@vger.kernel.org, linux-s390@vger.kernel.org, stable@vger.kernel.org References: <20210223191353.267981-1-imbrenda@linux.ibm.com> <20210223191353.267981-3-imbrenda@linux.ibm.com> From: David Hildenbrand Organization: Red Hat GmbH Subject: Re: [PATCH v4 2/2] s390/kvm: VSIE: correctly handle MVPG when in VSIE Message-ID: <2978d95c-62d9-556a-186f-9534e202f4c9@redhat.com> Date: Thu, 25 Feb 2021 20:12:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210223191353.267981-3-imbrenda@linux.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23.02.21 20:13, Claudio Imbrenda wrote: > Correctly handle the MVPG instruction when issued by a VSIE guest. > > Fixes: a3508fbe9dc6d ("KVM: s390: vsie: initial support for nested virtualization") > Cc: stable@vger.kernel.org > Signed-off-by: Claudio Imbrenda > Acked-by: Janosch Frank > --- > arch/s390/kvm/vsie.c | 93 +++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 88 insertions(+), 5 deletions(-) > > diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c > index 78b604326016..dbf4241bc2dc 100644 > --- a/arch/s390/kvm/vsie.c > +++ b/arch/s390/kvm/vsie.c > @@ -417,11 +417,6 @@ static void unshadow_scb(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) > memcpy((void *)((u64)scb_o + 0xc0), > (void *)((u64)scb_s + 0xc0), 0xf0 - 0xc0); > break; > - case ICPT_PARTEXEC: > - /* MVPG only */ > - memcpy((void *)((u64)scb_o + 0xc0), > - (void *)((u64)scb_s + 0xc0), 0xd0 - 0xc0); > - break; > } > > if (scb_s->ihcpu != 0xffffU) > @@ -983,6 +978,90 @@ static int handle_stfle(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) > return 0; > } > > +static u64 vsie_get_register(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page, u8 reg) > +{ > + reg &= 0xf; Nit, I'd mask of that value in the caller where you extract it from the ipb. ... > +static int vsie_handle_mvpg(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) > +{ > + struct kvm_s390_sie_block *scb_s = &vsie_page->scb_s; > + unsigned long pei_dest, pei_src, src, dest, mask = PAGE_MASK; > + u64 *pei_block = &vsie_page->scb_o->mcic; > + int edat, rc_dest, rc_src; > + union ctlreg0 cr0; ... const uint8_t r1 = (scb_s->ipb >> 16) & 0xf; const uint8_t r3 = (scb_s->ipb >> 20) & 0xf; (note: r1/r3 is just a guess ;) - and having the actual identifiers here will make the code easier to understand) > + > + cr0.val = vcpu->arch.sie_block->gcr[0]; > + edat = cr0.edat && test_kvm_facility(vcpu->kvm, 8); > + if (psw_bits(scb_s->gpsw).eaba == PSW_BITS_AMODE_24BIT) What about factoring out that masking like kvm_s390_logical_to_effective() introduce vsie_logical_to_effective() to handle that. > + mask = 0xfff000; > + else if (psw_bits(scb_s->gpsw).eaba == PSW_BITS_AMODE_31BIT) > + mask = 0x7ffff000; > + > + dest = vsie_get_register(vcpu, vsie_page, scb_s->ipb >> 16) & mask; > + src = vsie_get_register(vcpu, vsie_page, scb_s->ipb >> 20) & mask; > + > + rc_dest = kvm_s390_shadow_fault(vcpu, vsie_page->gmap, dest, &pei_dest); > + rc_src = kvm_s390_shadow_fault(vcpu, vsie_page->gmap, src, &pei_src); > + /* > + * Either everything went well, or something non-critical went wrong > + * e.g. beause of a race. In either case, simply retry. s/beause/because/ > + */ > + if (rc_dest == -EAGAIN || rc_src == -EAGAIN || (!rc_dest && !rc_src)) { > + retry_vsie_icpt(vsie_page); > + return -EAGAIN; I remember, because of the retry_vsie_icpt() you can simply return 0. Whatever you prefer. > + } > + /* Something more serious went wrong, propagate the error */ > + if (rc_dest < 0) > + return rc_dest; > + if (rc_src < 0) > + return rc_src; > + > + /* The only possible suppressing exception: just deliver it */ > + if (rc_dest == PGM_TRANSLATION_SPEC || rc_src == PGM_TRANSLATION_SPEC) { > + clear_vsie_icpt(vsie_page); > + rc_dest = kvm_s390_inject_program_int(vcpu, PGM_TRANSLATION_SPEC); > + WARN_ON_ONCE(rc_dest); > + return 1; > + } > + > + /* > + * Forward the PEI intercept to the guest if it was a page fault, or > + * also for segment and region table faults if EDAT applies. > + */ > + if (edat) { > + rc_dest = rc_dest == PGM_ASCE_TYPE ? rc_dest : 0; > + rc_src = rc_src == PGM_ASCE_TYPE ? rc_src : 0; > + } else { > + rc_dest = rc_dest != PGM_PAGE_TRANSLATION ? rc_dest : 0; > + rc_src = rc_src != PGM_PAGE_TRANSLATION ? rc_src : 0; > + } > + if (!rc_dest && !rc_src) { > + pei_block[0] = pei_dest; > + pei_block[1] = pei_src; > + return 1; > + } > + > + retry_vsie_icpt(vsie_page); > + > + /* > + * The host has edat, and the guest does not, or it was an ASCE type > + * exception. The host needs to inject the appropriate DAT interrupts > + * into the guest. > + */ > + if (rc_dest) > + return inject_fault(vcpu, rc_dest, dest, 1); > + return inject_fault(vcpu, rc_src, src, 0); The rc_dest and rc_src handling towards the end is a little confusing, but I have no real suggestion to make it easier to digest. Only some suggestions to make the code a bit nicer to read. Apart from that LGTM. Reviewed-by: David Hildenbrand -- Thanks, David / dhildenb