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=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 B3E6FC3A5A5 for ; Thu, 5 Sep 2019 09:11:49 +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 869D52145D for ; Thu, 5 Sep 2019 09:11:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="m9mkX3yh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 869D52145D 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=0YllX2d4PXx57kVW6wFRAtnEOUMVH4YrJneEN7ZAdAk=; b=m9mkX3yhiJAf59 ufaBbJ2xqsnHfWkBcfBpBSfJPI82Dz1C7iATcf+UJ2syBRnpFwF9xajb21IzZjyGGDFY74zsxy5m7 e+0YBtxr6aDrryJfz0v49FImQB6Cwo5IlQ1h0/82p/d1Bj2LSX7cVdc2c9AxSSN8d5uU4aTvXBkm7 o5/tYd4vdjeEgtAxTQ5NtidT+NW0crVAzya51Vspa13G7m+333Qoy4hFgO6lcy9q/1DtzVJBhTkSx 2NLnIIUGpypvwop+dCeejPakIhAcElMQ9FVlp7DF/zxczeFEPkGJCTfOEQLWEmSr0EobjuKVdhsEj ndFDQDre2neR7hDaEg/Q==; 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 1i5nnv-0007dZ-NO; Thu, 05 Sep 2019 09:11:47 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i5nns-0007cW-FG for linux-arm-kernel@lists.infradead.org; Thu, 05 Sep 2019 09:11:46 +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 D8C7F344; Thu, 5 Sep 2019 02:11:42 -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 649103F67D; Thu, 5 Sep 2019 02:11:40 -0700 (PDT) Date: Thu, 05 Sep 2019 10:11:38 +0100 Message-ID: <86lfv3rtth.wl-maz@kernel.org> From: Marc Zyngier To: Heinrich Schuchardt Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded In-Reply-To: <754fb77a-aace-e0aa-a5bb-a6c6bcff9890@gmx.de> References: <20190904180736.29009-1-xypron.glpk@gmx.de> <86r24vrwyh.wl-maz@kernel.org> <754fb77a-aace-e0aa-a5bb-a6c6bcff9890@gmx.de> 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_021144_599977_502B92BA X-CRM114-Status: GOOD ( 28.29 ) 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: Peter Maydell , =?UTF-8?B?IkRhbmllbCBQIC4gQmVycmFuZ8OpIg==?= , Suzuki K Pouloze , Julien Thierry , linux-kernel@vger.kernel.org, James Morse , Stefan Hajnoczi , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org 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:28:42 +0100, Heinrich Schuchardt wrote: > > On 9/5/19 10:03 AM, Marc Zyngier wrote: > > [Please use my kernel.org address. My arm.com address will disappear shortly] > > > > On Wed, 04 Sep 2019 19:07:36 +0100, > > Heinrich Schuchardt wrote: > >> > >> If an application tries to access memory that is not mapped, an error > >> ENOSYS, "load/store instruction decoding not implemented" may occur. > >> QEMU will hang with a register dump. > >> > >> Instead create a data abort that can be handled gracefully by the > >> application running in the virtual environment. > >> > >> Now the virtual machine can react to the event in the most appropriate > >> way - by recovering, by writing an informative log, or by rebooting. > >> > >> Signed-off-by: Heinrich Schuchardt > >> --- > >> virt/kvm/arm/mmio.c | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/virt/kvm/arm/mmio.c b/virt/kvm/arm/mmio.c > >> index a8a6a0c883f1..0cbed7d6a0f4 100644 > >> --- a/virt/kvm/arm/mmio.c > >> +++ b/virt/kvm/arm/mmio.c > >> @@ -161,8 +161,8 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run, > >> if (ret) > >> return ret; > >> } else { > >> - kvm_err("load/store instruction decoding not implemented\n"); > >> - return -ENOSYS; > >> + kvm_inject_dabt(vcpu, kvm_vcpu_get_hfar(vcpu)); > >> + return 1; > > > > 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. > > > > If you want to address this, consider forwarding the access to > > userspace. You'll only need an instruction decoder (supporting T1, T2, > > A32 and A64) and a S1 page table walker (one per page table format, > > all three of them) to emulate the access (having taken care of > > stopping all the other vcpus to make sure there is no concurrent > > modification of the page tables). You'll then be able to return the > > result of the access back to the kernel. > > If I understand you right, the problem has to be fixed in QEMU and not > in KVM. It is a shared responsibility. > Is there an example of such a forwarding already available in QEMU? Yes. That's how we ask userspace (QEMU) to perform a MMIO access on behalf of the guest (see how the run structure is populated and the vcpu thread returns to userspace). > > > > 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. > > My problem was to find out where in my guest (U-Boot running UEFI SCT) > the problem occurred. With this patch U-Boot gave me the relative > address in Shell.efi and I was able to locate what was wrong in U-Boot's > UEFI implementation. I understand that there is a need for more precise information. I'm just wary of adding debug features that become something that people rely on, despite being in contradiction with the architecture. I can help with the kernel side of the reporting, should someone want to tackle the userspace side of 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