Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1021498iob; Fri, 13 May 2022 19:58:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzKAKG4FsX0OTqLvuls8V0HQc7F6SBPAj8yRHdxPc3bYtI5nROqS6HYmPEkLmE9I7DCosTW X-Received: by 2002:adf:e887:0:b0:20a:c52f:e01a with SMTP id d7-20020adfe887000000b0020ac52fe01amr6087993wrm.42.1652497087441; Fri, 13 May 2022 19:58:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652497087; cv=none; d=google.com; s=arc-20160816; b=mkst3DBYpOU/096NKSBOjAyyPGCHPwkd8V7hVcGmwy7kUTOaUx/a6K9nLMp8Alio4a ugnhear5Ftmi8Bd3ekDCfiY8gO+QqxIFEa6zO6WljdvHnypv2XaFQH0MhBMKqYcSVcev YfCee7bo3SOBBfvr74E2yqIxvj+JVu1EZ+S2e9MG57TBCnhzl+nxE/viZNBnPdn9+geI d2hNWNfi8aNNdM0NVDtme/vbHjnJLF9bZsgMFdIpi1nf0Saii93ehv/zVFHV1ldSC698 DWyNK9y6TyzF4Vv1A9+lHSCT5f0e88XRQmVNvFxQTVLEvbiJTAxq+beKXgkB5YcsCKfb PKWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=gzLhFn1d7O2mtJvF5hDXUrpGu0kE6GQoNg6tjaVkOBg=; b=UP/uVmk2+l6cNy5Mnu34ArMauNrfKmya5UT+bkVkaJwTbYJZF7VnXi1YrQRVktKxS7 6TePLJNZyaFmltdyaWQILrss4ko/yxoDy9j5H3ecKHUJy/sdh9ynETh42chdyOqbk+Zl mZJjOxkw3wrjmuOiMYpQPo9sBw9hNCbdxIwYtRmFyw66TSvy/MXM/3g17/ksnBvIjnLS sGjnJgJ/0PI0Vc/LUb7ua3E5fKyOOFuyPOI3M7OiAS1e1E9XXSZv0ia0dIjKR6BEXiZ6 p1zeeyPoQdRK/NhcSZBFsj9xlQ6dFsPVLZTxwN3XC9hXYqehcNIJxHTs4+G6VuusNTPn /P2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=nMpjRGZ4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id z10-20020a1c4c0a000000b0039469d5af3fsi3769758wmf.188.2022.05.13.19.58.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 May 2022 19:58:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=nMpjRGZ4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0102E39736D; Fri, 13 May 2022 16:42:44 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1356480AbiELQ1I (ORCPT + 99 others); Thu, 12 May 2022 12:27:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44516 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356474AbiELQ1D (ORCPT ); Thu, 12 May 2022 12:27:03 -0400 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B578F39685; Thu, 12 May 2022 09:26:52 -0700 (PDT) Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 24CGAbaU014057; Thu, 12 May 2022 16:26:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=gzLhFn1d7O2mtJvF5hDXUrpGu0kE6GQoNg6tjaVkOBg=; b=nMpjRGZ4a3o0Lf/oOgHMnqql9eMrfKGMHwo/6MEmiL2d1zKt4OJS9s5vyUaG+B5Xtfmb NFc3rfCxVlgzeUezON1RP22u4YIIFTCmXyfLZjD/AKGJ2FAx3/klp3hUOREGcRku2HN4 VAEux1UbQkoz1OlcaAwlOMmG+08lQZlzlXLCCIaNVWBFoKJpBwqp40gryN0PTixZ51ul lpLvi6+tUc1zktThLJZJF+rJsf4Q/WCXz9/4cMymvUuS+6YKyGZXzdOqWUJ7kmRTmbdC HaVXDEiJBckrATtsPHgbCLVJms+1TNBW0mY0vatz8cM4e2T6Gy34wQSHwJdXy4wNW1QB Cg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3g155bgtrw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 May 2022 16:26:51 +0000 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 24CGEWRW032539; Thu, 12 May 2022 16:26:50 GMT Received: from ppma04ams.nl.ibm.com (63.31.33a9.ip4.static.sl-reverse.com [169.51.49.99]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3g155bgtr4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 May 2022 16:26:50 +0000 Received: from pps.filterd (ppma04ams.nl.ibm.com [127.0.0.1]) by ppma04ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 24CGHTBg019265; Thu, 12 May 2022 16:26:48 GMT Received: from b06avi18626390.portsmouth.uk.ibm.com (b06avi18626390.portsmouth.uk.ibm.com [9.149.26.192]) by ppma04ams.nl.ibm.com with ESMTP id 3fwgd8yaes-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 May 2022 16:26:48 +0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 24CGD67751052984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 May 2022 16:13:06 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 51FE642049; Thu, 12 May 2022 16:26:45 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BCB1642041; Thu, 12 May 2022 16:26:44 +0000 (GMT) Received: from [9.171.35.160] (unknown [9.171.35.160]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 12 May 2022 16:26:44 +0000 (GMT) Message-ID: <9ad7acb4-2729-15bb-7b25-eb95c4a12f09@linux.ibm.com> Date: Thu, 12 May 2022 18:26:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH v3 1/2] KVM: s390: Don't indicate suppression on dirtying, failing memop Content-Language: en-US To: David Hildenbrand , Janis Schoetterl-Glausch , Paolo Bonzini , Jonathan Corbet , Janosch Frank , Claudio Imbrenda , Heiko Carstens , Vasily Gorbik , Alexander Gordeev Cc: Sven Schnelle , kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org References: <20220512131019.2594948-1-scgl@linux.ibm.com> <20220512131019.2594948-2-scgl@linux.ibm.com> <77f6f5e7-5945-c478-0e41-affed62252eb@redhat.com> <4a06e3e8-4453-9204-eb66-d435860c5714@linux.ibm.com> <701033df-49c5-987e-b316-40835ad83d16@redhat.com> From: Christian Borntraeger In-Reply-To: <701033df-49c5-987e-b316-40835ad83d16@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: 4Hl7VkubwiwNUy3jI3wDZ5nauu-IAP56 X-Proofpoint-ORIG-GUID: 6A1JC_-JxCN6SwbqPoqNCX1GGAoWAidA X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-05-12_13,2022-05-12_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 impostorscore=0 mlxscore=0 clxscore=1015 bulkscore=0 mlxlogscore=999 phishscore=0 spamscore=0 malwarescore=0 suspectscore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205120076 X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 12.05.22 um 17:50 schrieb David Hildenbrand: > On 12.05.22 15:51, Christian Borntraeger wrote: >> >> >> Am 12.05.22 um 15:22 schrieb David Hildenbrand: >>> On 12.05.22 15:10, Janis Schoetterl-Glausch wrote: >>>> If user space uses a memop to emulate an instruction and that >>>> memop fails, the execution of the instruction ends. >>>> Instruction execution can end in different ways, one of which is >>>> suppression, which requires that the instruction execute like a no-op. >>>> A writing memop that spans multiple pages and fails due to key >>>> protection may have modified guest memory, as a result, the likely >>>> correct ending is termination. Therefore, do not indicate a >>>> suppressing instruction ending in this case. >>> >>> I think that is possibly problematic handling. >>> >>> In TCG we stumbled in similar issues in the past for MVC when crossing >>> page boundaries. Failing after modifying the first page already >>> seriously broke some user space, because the guest would retry the >>> instruction after fixing up the fault reason on the second page: if >>> source and destination operands overlap, you'll be in trouble because >>> the input parameters already changed. >>> >>> For this reason, in TCG we make sure that all accesses are valid before >>> starting modifications. >>> >>> See target/s390x/tcg/mem_helper.c:do_helper_mvc with access_prepare() >>> and friends as an example. >>> >>> Now, I don't know how to tackle that for KVM, I just wanted to raise >>> awareness that injecting an interrupt after modifying page content is >>> possible dodgy and dangerous. >> >> this is really special and only for key protection crossing pages. >> Its been done since the 70ies in that way on z/VM. The architecture >> is and was always written in a way to allow termination for this >> case for hypervisors. > > Just so I understand correctly: all instructions that a hypervisor with > hardware virtualization is supposed to emulate are "written in a way to > allow termination", correct? That makes things a lot easier. Only for key protection. Key protection can always be terminating no matter what the instruction says. This is historical baggage - key protection was resulting in abends - killing the process. So it does not matter if we provide the extra info as in enhanced suppression on protection as nobody is making use of that (apart from debuggers maybe).