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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 41F25C3A5AA for ; Thu, 5 Sep 2019 08:25:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 217EA20870 for ; Thu, 5 Sep 2019 08:25:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732454AbfIEIZG (ORCPT ); Thu, 5 Sep 2019 04:25:06 -0400 Received: from foss.arm.com ([217.140.110.172]:39202 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726115AbfIEIZF (ORCPT ); Thu, 5 Sep 2019 04:25:05 -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 0EF7C337; Thu, 5 Sep 2019 01:25:05 -0700 (PDT) Received: from localhost (e113682-lin.copenhagen.arm.com [10.32.144.41]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 94E2A3F67D; Thu, 5 Sep 2019 01:25:04 -0700 (PDT) Date: Thu, 5 Sep 2019 10:25:03 +0200 From: Christoffer Dall To: Peter Maydell Cc: Marc Zyngier , Daniel P =?utf-8?B?LiBCZXJyYW5nw6k=?= , Heinrich Schuchardt , lkml - Kernel Mailing List , Stefan Hajnoczi , kvmarm@lists.cs.columbia.edu, arm-mail-list Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded Message-ID: <20190905082503.GB4320@e113682-lin.lund.arm.com> References: <20190904180736.29009-1-xypron.glpk@gmx.de> <86r24vrwyh.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 05, 2019 at 09:16:54AM +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 :-) > > > 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... > Is it really going to be easier to debug a guest that sees behavior which may not be architecturally correct? For example, seeing a data abort on an access to an MMIO region because the guest used a strange instruction? I appreaciate that the current way we handle this is confusing and has led many people down a rabbit hole, so we should do better. Would a better approach not be to return to userspace saying, "we can't handle this in the kernel, you decide", without printing the dubious kernel error message. Then user space could suspend the VM and print a lenghty explanation of all the possible problems there could be, or re-inject something back into the guest, or whatever, for a particular environment. Thoughts? Thanks, Christoffer 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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 9D46EC3A5A5 for ; Thu, 5 Sep 2019 08:25:10 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 2C05B20870 for ; Thu, 5 Sep 2019 08:25:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C05B20870 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com 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 81F7C4A59B; Thu, 5 Sep 2019 04:25:09 -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 cOHGPeq8JOmZ; Thu, 5 Sep 2019 04:25:08 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 3E3A94A554; Thu, 5 Sep 2019 04:25:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id DFA554A528 for ; Thu, 5 Sep 2019 04:25:06 -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 cN1Jr8aREa5j for ; Thu, 5 Sep 2019 04:25:05 -0400 (EDT) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 754E44A522 for ; Thu, 5 Sep 2019 04:25:05 -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 0EF7C337; Thu, 5 Sep 2019 01:25:05 -0700 (PDT) Received: from localhost (e113682-lin.copenhagen.arm.com [10.32.144.41]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 94E2A3F67D; Thu, 5 Sep 2019 01:25:04 -0700 (PDT) Date: Thu, 5 Sep 2019 10:25:03 +0200 From: Christoffer Dall To: Peter Maydell Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded Message-ID: <20190905082503.GB4320@e113682-lin.lund.arm.com> References: <20190904180736.29009-1-xypron.glpk@gmx.de> <86r24vrwyh.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Daniel P =?utf-8?B?LiBCZXJyYW5nw6k=?= , Marc Zyngier , lkml - Kernel Mailing List , Stefan Hajnoczi , Heinrich Schuchardt , 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, Sep 05, 2019 at 09:16:54AM +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 :-) > > > 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... > Is it really going to be easier to debug a guest that sees behavior which may not be architecturally correct? For example, seeing a data abort on an access to an MMIO region because the guest used a strange instruction? I appreaciate that the current way we handle this is confusing and has led many people down a rabbit hole, so we should do better. Would a better approach not be to return to userspace saying, "we can't handle this in the kernel, you decide", without printing the dubious kernel error message. Then user space could suspend the VM and print a lenghty explanation of all the possible problems there could be, or re-inject something back into the guest, or whatever, for a particular environment. Thoughts? Thanks, Christoffer _______________________________________________ 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=-2.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 9ACD6C3A5A5 for ; Thu, 5 Sep 2019 08:25:14 +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 6D1F120870 for ; Thu, 5 Sep 2019 08:25:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mj3L0Vin" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D1F120870 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com 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:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=PTC41mOAYujRtnckaoBWanI3zjmktlUHs6pvxI916Zk=; b=mj3L0VinSlaL4g k9WNPFySsXpvOuqSxN5jOyVZ0uCUY66Q8On0kZ2IIRaNjVsPPSzRInCvE3KgedB0g03x2XoMTiUkK zGzgIYex6k6atqbeca7hJrJOkbMZo8jLemDZJ3mviZCZGunSCqM2XBeglOzZPyViKIpChznP3gjOt NltPJudfJTG1cln8Ol/Txe5A6x7AknlsGkg2navhfAheyEzrMpwFHPGNltb7x3ojnvWfIaiECcoCG sgV3xcknG0M3ZcEwIHfqoKlVl9I++jHofA3AIslsaGzFkLUxp3XNN4jS9NCA+q/VJtiGJJckiaSxr PGAB4g8Cn1Owc+WlMUWw==; 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 1i5n4n-0005Kl-Pq; Thu, 05 Sep 2019 08:25:09 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i5n4l-0004wt-B1 for linux-arm-kernel@lists.infradead.org; Thu, 05 Sep 2019 08:25:08 +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 0EF7C337; Thu, 5 Sep 2019 01:25:05 -0700 (PDT) Received: from localhost (e113682-lin.copenhagen.arm.com [10.32.144.41]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 94E2A3F67D; Thu, 5 Sep 2019 01:25:04 -0700 (PDT) Date: Thu, 5 Sep 2019 10:25:03 +0200 From: Christoffer Dall To: Peter Maydell Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded Message-ID: <20190905082503.GB4320@e113682-lin.lund.arm.com> References: <20190904180736.29009-1-xypron.glpk@gmx.de> <86r24vrwyh.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190905_012507_430447_1E4C8368 X-CRM114-Status: GOOD ( 18.97 ) 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: Daniel P =?utf-8?B?LiBCZXJyYW5nw6k=?= , Marc Zyngier , lkml - Kernel Mailing List , Stefan Hajnoczi , Heinrich Schuchardt , 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, Sep 05, 2019 at 09:16:54AM +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 :-) > > > 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... > Is it really going to be easier to debug a guest that sees behavior which may not be architecturally correct? For example, seeing a data abort on an access to an MMIO region because the guest used a strange instruction? I appreaciate that the current way we handle this is confusing and has led many people down a rabbit hole, so we should do better. Would a better approach not be to return to userspace saying, "we can't handle this in the kernel, you decide", without printing the dubious kernel error message. Then user space could suspend the VM and print a lenghty explanation of all the possible problems there could be, or re-inject something back into the guest, or whatever, for a particular environment. Thoughts? Thanks, Christoffer _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel