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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 62B53C3A5A5 for ; Thu, 5 Sep 2019 08:52:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 365DC21743 for ; Thu, 5 Sep 2019 08:52:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1567673562; bh=Vwr1OGbeWmeciGTqgCwPbmyklLB7HJwi8iFnUYpVSiM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=joyfw2qc7UUclnBu2DzntQKUJqn08p+NeftTp5kt+y3XC2iUro+9n+68iX/rX9yvr iiXQJ5ZODtXf6nfAU5P3gTaDZ0qKRN1yh89YVXTgjn+wDxS5Ej03vShwvYg2CzNlOR 0riaZOoWN8af8FG+bBKcO856kbfhTthX+vOmjsCc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732833AbfIEIwl (ORCPT ); Thu, 5 Sep 2019 04:52:41 -0400 Received: from foss.arm.com ([217.140.110.172]:39608 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732205AbfIEIwk (ORCPT ); Thu, 5 Sep 2019 04:52:40 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6AA23337; Thu, 5 Sep 2019 01:52:40 -0700 (PDT) Received: from big-swifty.misterjones.org (unknown [10.1.27.38]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 205A93F67D; Thu, 5 Sep 2019 01:52:37 -0700 (PDT) Date: Thu, 05 Sep 2019 09:52:36 +0100 Message-ID: <86mufjrup7.wl-maz@kernel.org> From: Marc Zyngier To: Peter Maydell Cc: Heinrich Schuchardt , James Morse , Julien Thierry , Suzuki K Pouloze , Stefan Hajnoczi , =?UTF-8?B?IkRhbmllbCBQIC4gQmVycmFuZ8OpIg==?= , arm-mail-list , kvmarm@lists.cs.columbia.edu, lkml - Kernel Mailing List Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded In-Reply-To: References: <20190904180736.29009-1-xypron.glpk@gmx.de> <86r24vrwyh.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: Approximate MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 05 Sep 2019 09:16:54 +0100, Peter Maydell wrote: > > On Thu, 5 Sep 2019 at 09:04, Marc Zyngier wrote: > > How can you tell that the access would fault? You have no idea at that > > stage (the kernel doesn't know about the MMIO ranges that userspace > > handles). All you know is that you're faced with a memory access that > > you cannot emulate in the kernel. Injecting a data abort at that stage > > is not something that the architecture allows. > > To be fair, locking up the whole CPU (which is effectively > what the kvm_err/ENOSYS is going to do to the VM) isn't > something the architecture allows either :-) Hey, I didn't say things were good as they are now! ;-) I'm definitely willing to change things in that area, but I also don't want anyone to start relying on things that are not specified anywhere. > > > Of course, the best thing would be to actually fix the guest so that > > it doesn't use non-emulatable MMIO accesses. In general, that the sign > > of a bug in low-level accessors. > > This is true, but the problem is that barfing out to userspace > makes it harder to debug the guest because it means that > the VM is immediately destroyed, whereas AIUI if we > inject some kind of exception then (assuming you're set up > to do kernel-debug via gdbstub) you can actually examine > the offending guest code with a debugger because at least > your VM is still around to inspect... To Christoffer's point, I find the benefit a bit dubious. Yes, you get an exception, but the instruction that caused it may be completely legal (store with post-increment, for example), leading to an even more puzzled developer (that exception should never have been delivered the first place). I'm far more in favour of dumping the state of the access in the run structure (much like we do for a MMIO access) and let userspace do something about it (such as dumping information on the console or breaking). It could even inject an exception *if* the user has asked for it. Thanks, M. -- Jazz is not dead, it just smells funny. 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=-1.0 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 71458C3A5A5 for ; Thu, 5 Sep 2019 08:52:46 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 04AF32145D for ; Thu, 5 Sep 2019 08:52:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 04AF32145D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6D6BC4A525; Thu, 5 Sep 2019 04:52:45 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmlhNTPZl4IQ; Thu, 5 Sep 2019 04:52:44 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4DA1A4A554; Thu, 5 Sep 2019 04:52:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 8D7F84A525 for ; Thu, 5 Sep 2019 04:52:42 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huqs2n8kjZqP for ; Thu, 5 Sep 2019 04:52:40 -0400 (EDT) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mm01.cs.columbia.edu (Postfix) with ESMTP id BB23D4A522 for ; Thu, 5 Sep 2019 04:52:40 -0400 (EDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6AA23337; Thu, 5 Sep 2019 01:52:40 -0700 (PDT) Received: from big-swifty.misterjones.org (unknown [10.1.27.38]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 205A93F67D; Thu, 5 Sep 2019 01:52:37 -0700 (PDT) Date: Thu, 05 Sep 2019 09:52:36 +0100 Message-ID: <86mufjrup7.wl-maz@kernel.org> From: Marc Zyngier To: Peter Maydell Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded In-Reply-To: References: <20190904180736.29009-1-xypron.glpk@gmx.de> <86r24vrwyh.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: Approximate MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Cc: =?UTF-8?B?IkRhbmllbCBQIC4gQmVycmFuZ8OpIg==?= , Heinrich Schuchardt , lkml - Kernel Mailing List , Stefan Hajnoczi , kvmarm@lists.cs.columbia.edu, arm-mail-list X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Thu, 05 Sep 2019 09:16:54 +0100, Peter Maydell wrote: > > On Thu, 5 Sep 2019 at 09:04, Marc Zyngier wrote: > > How can you tell that the access would fault? You have no idea at that > > stage (the kernel doesn't know about the MMIO ranges that userspace > > handles). All you know is that you're faced with a memory access that > > you cannot emulate in the kernel. Injecting a data abort at that stage > > is not something that the architecture allows. > > To be fair, locking up the whole CPU (which is effectively > what the kvm_err/ENOSYS is going to do to the VM) isn't > something the architecture allows either :-) Hey, I didn't say things were good as they are now! ;-) I'm definitely willing to change things in that area, but I also don't want anyone to start relying on things that are not specified anywhere. > > > Of course, the best thing would be to actually fix the guest so that > > it doesn't use non-emulatable MMIO accesses. In general, that the sign > > of a bug in low-level accessors. > > This is true, but the problem is that barfing out to userspace > makes it harder to debug the guest because it means that > the VM is immediately destroyed, whereas AIUI if we > inject some kind of exception then (assuming you're set up > to do kernel-debug via gdbstub) you can actually examine > the offending guest code with a debugger because at least > your VM is still around to inspect... To Christoffer's point, I find the benefit a bit dubious. Yes, you get an exception, but the instruction that caused it may be completely legal (store with post-increment, for example), leading to an even more puzzled developer (that exception should never have been delivered the first place). I'm far more in favour of dumping the state of the access in the run structure (much like we do for a MMIO access) and let userspace do something about it (such as dumping information on the console or breaking). It could even inject an exception *if* the user has asked for it. Thanks, M. -- Jazz is not dead, it just smells funny. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 C26CBC3A5A5 for ; Thu, 5 Sep 2019 08:52:51 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9416F21848 for ; Thu, 5 Sep 2019 08:52:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ioq2FTHO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9416F21848 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=TwyF+nSiKLM/lO+S8d/IdLgGBv/n6ESO5pobrmnwJrU=; b=ioq2FTHOyK9oJ1 /qt6H1wNPVmi+iHXWiZ3xZlgACL8p9zTAf2o6dPz88avZ0n+crOK+Xe1Zf2/MmLyO2n4M/XD8fdNx RniUp6ZPoeNN36jpwKWRjtoTje5utUdzQaK7WAwts6pXMuyful4r6muob/9NLo3mgLTssupwoNJ2t 6cWETaJUpS87hKNjRP2kGK6vx+jCbBsRmkE20OFZam5CuYLpuxsaQRgCCP8ryA7v4A6njerG5hd+Z 6vNAZPR/joKYSc/MxqLmHXcgEXMIuWPFU8CA4C3nJTfQJf4TqgIluuGUEX3uIeczsE4i2y58lSAC2 2qPjAWerb6QEy/VX5wWw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i5nVU-0007L2-KV; Thu, 05 Sep 2019 08:52:44 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i5nVR-0007KJ-FT for linux-arm-kernel@lists.infradead.org; Thu, 05 Sep 2019 08:52:42 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6AA23337; Thu, 5 Sep 2019 01:52:40 -0700 (PDT) Received: from big-swifty.misterjones.org (unknown [10.1.27.38]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 205A93F67D; Thu, 5 Sep 2019 01:52:37 -0700 (PDT) Date: Thu, 05 Sep 2019 09:52:36 +0100 Message-ID: <86mufjrup7.wl-maz@kernel.org> From: Marc Zyngier To: Peter Maydell Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded In-Reply-To: References: <20190904180736.29009-1-xypron.glpk@gmx.de> <86r24vrwyh.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: Approximate MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190905_015241_563131_BADAFB73 X-CRM114-Status: GOOD ( 19.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?B?IkRhbmllbCBQIC4gQmVycmFuZ8OpIg==?= , Suzuki K Pouloze , Heinrich Schuchardt , Julien Thierry , lkml - Kernel Mailing List , James Morse , Stefan Hajnoczi , kvmarm@lists.cs.columbia.edu, arm-mail-list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 05 Sep 2019 09:16:54 +0100, Peter Maydell wrote: > > On Thu, 5 Sep 2019 at 09:04, Marc Zyngier wrote: > > How can you tell that the access would fault? You have no idea at that > > stage (the kernel doesn't know about the MMIO ranges that userspace > > handles). All you know is that you're faced with a memory access that > > you cannot emulate in the kernel. Injecting a data abort at that stage > > is not something that the architecture allows. > > To be fair, locking up the whole CPU (which is effectively > what the kvm_err/ENOSYS is going to do to the VM) isn't > something the architecture allows either :-) Hey, I didn't say things were good as they are now! ;-) I'm definitely willing to change things in that area, but I also don't want anyone to start relying on things that are not specified anywhere. > > > Of course, the best thing would be to actually fix the guest so that > > it doesn't use non-emulatable MMIO accesses. In general, that the sign > > of a bug in low-level accessors. > > This is true, but the problem is that barfing out to userspace > makes it harder to debug the guest because it means that > the VM is immediately destroyed, whereas AIUI if we > inject some kind of exception then (assuming you're set up > to do kernel-debug via gdbstub) you can actually examine > the offending guest code with a debugger because at least > your VM is still around to inspect... To Christoffer's point, I find the benefit a bit dubious. Yes, you get an exception, but the instruction that caused it may be completely legal (store with post-increment, for example), leading to an even more puzzled developer (that exception should never have been delivered the first place). I'm far more in favour of dumping the state of the access in the run structure (much like we do for a MMIO access) and let userspace do something about it (such as dumping information on the console or breaking). It could even inject an exception *if* the user has asked for it. Thanks, M. -- Jazz is not dead, it just smells funny. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel