Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3420489pxu; Sun, 20 Dec 2020 02:17:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJwl1U4SrM5P6RDpwTrOkD+yHUVQMYZkiJyrnYpg/U6UDEHWEVpsO653zF9IiCfxQK+5nzWM X-Received: by 2002:a17:906:b2d1:: with SMTP id cf17mr11476781ejb.281.1608459464180; Sun, 20 Dec 2020 02:17:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608459464; cv=none; d=google.com; s=arc-20160816; b=XvpCOp3YsWF8s6/2+omKulTcbiwuspS2KVR+jLNe0Ul/30uCp1WmczgSRy2OQ7h+2r i/BEnXNQ1pOM8mEMRns0IoXMpwKKCbrOoy/A80BQF2diZo3dQ/9nEXejp3D0h3CxNwxW 7sCbh8ebCclTPUa8GsbEjEVzik/cC72BBZlkvpGUarfTU3hcn6vnYLvwHk9iD5DZmeQj n7PyrENs7xf7zJHLcqxIVQn9jHubK8iuyBlNfxBLWYapaZCR+Lik5Kdq0/eRDJQ69JSs UDHsyxs0zIOHayNYx2ePsgA0LOxw9lv70u8lownMtvpgxv4IZGVfi2cDDtOdcgWSVW6b RtKA== 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=L7WBlnc4uBH3yp60EsaVmDi0Gnm0WESlPJ7pAkexlYE=; b=LDe5BCFBuUESK4qll36Oqq8UChanp6iPqRXPLxCMa5qnSvLQcrHykEbGfdC1cEfxeZ WrEL+U/TsgEYHZWJqEVeqr5RaUArndqJ1U8wCEtvhrOnbvKLNSaGrNN1Wbi90LlK8Snu AopaVvc2RBu6CQSaQ0ugqIWxitmfgx06JZmJQ+BvVfR3rqUbof68NCdpnO1IY57u+VGx oTYVdrmAOwcpTXcZOrPPiOerLPtjlXpj6isRQVLyMs4rgUGpSLVgJAJYzlBN0omydk7I 4uYgxeM9400FQ6WkDC0Ln8DaOYu1QCFLYFBPha18IX6fV90zf2Z2tw+Cpc6HQdFduip7 g8yA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=DRy611g2; 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 f12si8574502ejl.311.2020.12.20.02.17.05; Sun, 20 Dec 2020 02:17:44 -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=DRy611g2; 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 S1727298AbgLTKPa (ORCPT + 99 others); Sun, 20 Dec 2020 05:15:30 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:25789 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726849AbgLTKPa (ORCPT ); Sun, 20 Dec 2020 05:15:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1608459243; 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=L7WBlnc4uBH3yp60EsaVmDi0Gnm0WESlPJ7pAkexlYE=; b=DRy611g2dWyYHGJ6E0rKQqgcsFC1pYd2V4n23wkCciITpt08V4+/SijjNNdwLqvLiB+ozu mwo7rGasgm2Lo4YJA0SacV3BA0svf0GCiY7cZ3SwyMNuar+YqvGF7cwsYwwRZ39MO2NEEW FuZ3TdC6mHUGcDy83zKzW5Rs0v7AA3M= 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-99-EkyDCo7HO9-EaJpq7SKZJg-1; Sun, 20 Dec 2020 05:14:01 -0500 X-MC-Unique: EkyDCo7HO9-EaJpq7SKZJg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2519615720; Sun, 20 Dec 2020 10:14:00 +0000 (UTC) Received: from [10.36.112.16] (ovpn-112-16.ams2.redhat.com [10.36.112.16]) by smtp.corp.redhat.com (Postfix) with ESMTP id A9D996294D; Sun, 20 Dec 2020 10:13:58 +0000 (UTC) Subject: Re: [PATCH v1 4/4] s390/kvm: VSIE: correctly handle MVPG when in VSIE To: Claudio Imbrenda , linux-kernel@vger.kernel.org Cc: borntraeger@de.ibm.com, frankja@linux.ibm.com, kvm@vger.kernel.org, linux-s390@vger.kernel.org, stable@vger.kernel.org References: <20201218141811.310267-1-imbrenda@linux.ibm.com> <20201218141811.310267-5-imbrenda@linux.ibm.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <6836573a-a49d-9d9f-49e0-96b5aa479c52@redhat.com> Date: Sun, 20 Dec 2020 11:13:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201218141811.310267-5-imbrenda@linux.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18.12.20 15:18, Claudio Imbrenda wrote: > Correctly handle the MVPG instruction when issued by a VSIE guest. > I remember that MVPG SIE documentation was completely crazy and full of corner cases. :) Looking at arch/s390/kvm/intercept.c:handle_mvpg_pei(), I can spot that 1. "This interception can only happen for guests with DAT disabled ..." 2. KVM does not make use of any mvpg state inside the SCB. Can this be observed with Linux guests? Can I get some information on what information is stored at [0xc0, 0xd) inside the SCB? I assume it's: 0xc0: guest physical address of source PTE 0xc8: guest physical address of target PTE Also, which conditions have to be met such that we get a ICPT_PARTEXEC: a) State of guest DAT (I assume off?) b) State of PTEs: What happens if there is no PTE (I assume we need two PTEs, otherwise no such intercept)? I assume we get an intercept if one of both PTEs is not present or the destination PTE is protected. Correct? So, when we (g1) get an intercept for g3, can we be sure 0xc0 and 0xc8 in the scb are both valid g1 addresses pointing at our PTE, and what do we know about these PTEs (one not present or destination protected)? [...] > /* > * Run the vsie on a shadow scb and a shadow gmap, without any further > * sanity checks, handling SIE faults. > @@ -1063,6 +1132,10 @@ static int do_vsie_run(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) > if ((scb_s->ipa & 0xf000) != 0xf000) > scb_s->ipa += 0x1000; > break; > + case ICPT_PARTEXEC: > + if (scb_s->ipa == 0xb254) Old code hat "/* MVPG only */" - why is this condition now necessary? > + rc = vsie_handle_mvpg(vcpu, vsie_page); > + break; > } > return rc; > } > -- Thanks, David / dhildenb