From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81DB5C3526C for ; Sun, 20 Dec 2020 10:15:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5194222D72 for ; Sun, 20 Dec 2020 10:15:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727339AbgLTKPb (ORCPT ); Sun, 20 Dec 2020 05:15:31 -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