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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 E9983C3A5A5 for ; Thu, 5 Sep 2019 08:56:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BBE1F2145D for ; Thu, 5 Sep 2019 08:56:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="jMQkaaRR" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732890AbfIEI45 (ORCPT ); Thu, 5 Sep 2019 04:56:57 -0400 Received: from mail-oi1-f193.google.com ([209.85.167.193]:40291 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726231AbfIEI45 (ORCPT ); Thu, 5 Sep 2019 04:56:57 -0400 Received: by mail-oi1-f193.google.com with SMTP id b80so1157969oii.7 for ; Thu, 05 Sep 2019 01:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IaZJ01VOJ44Z6Y9Qs3oUQiygt2Sy6fVI1ZsDthTYEac=; b=jMQkaaRRxSCpAfa0GGbTxN8sdW3BCz1aSdR6b+EoXx/Ue0KZCOzdiDMjAbfR7+eunv kx6XBxSzt7twCIJybPMD0h4eaU9yCitmULNsKZtsM1dUaTLn0IRFZwSO/spnqaAIn/WK smp1BnN01ssm7CCtza47yOcSEOeIXZ1ZULlSTfRZOEsNqdrJ7B42GvgGl8dAkW5Gxttk u9esLSmQOOsONHcK/RUZ141vgbuInB0YtTAbMwB/kfkNXGOaqNn3qNIWIPfg6k2EvkkU XJaDvfUoQwhTXwEmZVrsd8airEaBOdhwLNIkte996VruPPflokhLzMWXcXhvYQ73j8Px FatA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IaZJ01VOJ44Z6Y9Qs3oUQiygt2Sy6fVI1ZsDthTYEac=; b=oGrDXcSpOTs/QH1kp+44p4djkferyHWDDeKpxhMAjNatEnfvwqSk4vVRXXKWVI0lSi hHqsKA3ybOumhbMciklM+kVYerHiabItEwHSTkuYXYF8+o7H/5YEnzMoIVxX45zGfefy cGSyetwEibRjXWtVla2ksVuUOqvtz5pmw6qGUg834DmE18uQxgQgj1ZxyK3xgFL89Oxl 6uz2Wa7+dIfRjnSeeHmk4XpnUR4aJHpGFfw6/luh7jlN7mqxLEvfHs7Om4vKfceV8KZu ZHE5b/pUK/vpa9vt9D28Vo9tPrGtKCE3Dy2sdVlBAiVmeDkt0boYJe7+RVzc6M3nA0KC Rqag== X-Gm-Message-State: APjAAAVlLqjAu8QmrwsdS0mWNns2fNxP+FxMZiuMny1vgSv9m9A7PEkn W6dv+8rwcezhLlFuQtj8Zy+721R4/z6wz503m5h+RQ== X-Google-Smtp-Source: APXvYqwoy7MTqB4H3mDdtS3aRDNvVJhhOoQARzpS77k98EfHG9CbyovynxJ3OmaOX9n7dO2thM4lg6LAw11dh4CzMMw= X-Received: by 2002:aca:f54d:: with SMTP id t74mr1740404oih.170.1567673816212; Thu, 05 Sep 2019 01:56:56 -0700 (PDT) MIME-Version: 1.0 References: <20190904180736.29009-1-xypron.glpk@gmx.de> <86r24vrwyh.wl-maz@kernel.org> <86mufjrup7.wl-maz@kernel.org> In-Reply-To: <86mufjrup7.wl-maz@kernel.org> From: Peter Maydell Date: Thu, 5 Sep 2019 09:56:44 +0100 Message-ID: Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded To: Marc Zyngier Cc: Heinrich Schuchardt , James Morse , Julien Thierry , Suzuki K Pouloze , Stefan Hajnoczi , =?UTF-8?Q?Daniel_P_=2E_Berrang=C3=A9?= , arm-mail-list , kvmarm@lists.cs.columbia.edu, lkml - Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 5 Sep 2019 at 09:52, Marc Zyngier wrote: > > On Thu, 05 Sep 2019 09:16:54 +0100, > Peter Maydell wrote: > > 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). Right, but the combination of "host kernel prints a message about an unsupported load/store insn" and "within-guest debug dump/stack trace/etc" is much more useful than just having "host kernel prints message" and "QEMU exits"; and it requires about 3 lines of code change... > 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. ...whereas this requires agreement on a kernel-userspace API, larger changes in the kernel, somebody to implement the userspace side of things, and the user to update both the kernel and QEMU. It's hard for me to see that the benefit here over the 3-line approach really outweighs the extra effort needed. In practice saying "we should do this" is saying "we're going to do nothing", based on the historical record. thanks -- PMM 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=-0.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,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 2887AC3A5A5 for ; Thu, 5 Sep 2019 08:57:02 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id A347621848 for ; Thu, 5 Sep 2019 08:57:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="jMQkaaRR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A347621848 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.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 08F0C4A5AF; Thu, 5 Sep 2019 04:57:01 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@linaro.org 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 rQ9Slj7F3847; Thu, 5 Sep 2019 04:56:59 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C021A4A57A; Thu, 5 Sep 2019 04:56:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4BE514A525 for ; Thu, 5 Sep 2019 04:56:58 -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 v5dF5Mt6xu0Y for ; Thu, 5 Sep 2019 04:56:57 -0400 (EDT) Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 22E944A522 for ; Thu, 5 Sep 2019 04:56:57 -0400 (EDT) Received: by mail-oi1-f193.google.com with SMTP id w144so1166363oia.6 for ; Thu, 05 Sep 2019 01:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IaZJ01VOJ44Z6Y9Qs3oUQiygt2Sy6fVI1ZsDthTYEac=; b=jMQkaaRRxSCpAfa0GGbTxN8sdW3BCz1aSdR6b+EoXx/Ue0KZCOzdiDMjAbfR7+eunv kx6XBxSzt7twCIJybPMD0h4eaU9yCitmULNsKZtsM1dUaTLn0IRFZwSO/spnqaAIn/WK smp1BnN01ssm7CCtza47yOcSEOeIXZ1ZULlSTfRZOEsNqdrJ7B42GvgGl8dAkW5Gxttk u9esLSmQOOsONHcK/RUZ141vgbuInB0YtTAbMwB/kfkNXGOaqNn3qNIWIPfg6k2EvkkU XJaDvfUoQwhTXwEmZVrsd8airEaBOdhwLNIkte996VruPPflokhLzMWXcXhvYQ73j8Px FatA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IaZJ01VOJ44Z6Y9Qs3oUQiygt2Sy6fVI1ZsDthTYEac=; b=ASLRyvyWEJ/qFh1Gp4F5Fd3cLwaR031SwY29eRLCIlKXbN4TDAVQc5wf8T7C9Jd7dM pTy1EjQ9lpMDlKVx5qSzjZ4cE18211vqJhEiKXRbs4c4ctQldGjIkVcqkYZRoBMPZHFL /kFtFpXbDCF1z5F0lYSemkICB4PcethMDxkW2QmiavSSN2oXbvKrkxDmcVKNMSQXsBF7 UEzRFCS15jYXKVG+fuKcYKWUsI7JgIcLWT+hpXQ8kEUcPNzxLuWn7GKahgz6Cx59GRDv 6DHGB1WKol1uQmU5V4ucHiA7SnD01cvb38WllaI8RXf6KMN7XZAGIAfJSMCxTJzH+IQv 7gmQ== X-Gm-Message-State: APjAAAXpVPVcaqltkxOTaRhqtnXgHcnmgBBZtzdOpeGaBln/Mef17mQ5 cMVX+kT3BmFhDaM2nztkO0QetMWKG3awKovn/xbemA== X-Google-Smtp-Source: APXvYqwoy7MTqB4H3mDdtS3aRDNvVJhhOoQARzpS77k98EfHG9CbyovynxJ3OmaOX9n7dO2thM4lg6LAw11dh4CzMMw= X-Received: by 2002:aca:f54d:: with SMTP id t74mr1740404oih.170.1567673816212; Thu, 05 Sep 2019 01:56:56 -0700 (PDT) MIME-Version: 1.0 References: <20190904180736.29009-1-xypron.glpk@gmx.de> <86r24vrwyh.wl-maz@kernel.org> <86mufjrup7.wl-maz@kernel.org> In-Reply-To: <86mufjrup7.wl-maz@kernel.org> From: Peter Maydell Date: Thu, 5 Sep 2019 09:56:44 +0100 Message-ID: Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded To: Marc Zyngier Cc: =?UTF-8?Q?Daniel_P_=2E_Berrang=C3=A9?= , 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, 5 Sep 2019 at 09:52, Marc Zyngier wrote: > > On Thu, 05 Sep 2019 09:16:54 +0100, > Peter Maydell wrote: > > 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). Right, but the combination of "host kernel prints a message about an unsupported load/store insn" and "within-guest debug dump/stack trace/etc" is much more useful than just having "host kernel prints message" and "QEMU exits"; and it requires about 3 lines of code change... > 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. ...whereas this requires agreement on a kernel-userspace API, larger changes in the kernel, somebody to implement the userspace side of things, and the user to update both the kernel and QEMU. It's hard for me to see that the benefit here over the 3-line approach really outweighs the extra effort needed. In practice saying "we should do this" is saying "we're going to do nothing", based on the historical record. thanks -- PMM _______________________________________________ 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=-0.8 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 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 E09FAC3A5A5 for ; Thu, 5 Sep 2019 08:57:05 +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 B1EA621848 for ; Thu, 5 Sep 2019 08:57:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="qo+2bqIc"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="jMQkaaRR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B1EA621848 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.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:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=waSoEv3aso4LG2jlWMrPbpVpjT8wpWxdzgX9vWJmg0Q=; b=qo+2bqIcyubREN /MPmkvDre/SBl6L/E6RkiBEy1WLxQvngjLEdgmno+FgTv9ilNz9oZ0EMDD7fuDQ5Z0Qi3qFZmaJeL uqxJWQRIsb2/pzGRvgIPZnQKjhvWWWxx+83Ov21W7JdAPn3faX76x0X0WNbZGTXnyiE7F3atDRqZ0 phImLvKlJkQo1B6DZaEU9l7QnxhBdQSjfkgT3VpB9iJyhsnoOzeggk8668hSy8hEbf6pO1aAw7feu yQ8NsfGyXajSKeeDYOkEYwhZNSlwJ/amRwQrlNEvmgHgy1aO2wsqR+MYReDbrW58VVKWitu11kCV0 sGkQO8I1brJ6gygONcHw==; 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 1i5nZc-0000pg-Jr; Thu, 05 Sep 2019 08:57:00 +0000 Received: from mail-oi1-x242.google.com ([2607:f8b0:4864:20::242]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1i5nZZ-0000pI-Ji for linux-arm-kernel@lists.infradead.org; Thu, 05 Sep 2019 08:56:59 +0000 Received: by mail-oi1-x242.google.com with SMTP id v7so1177440oib.4 for ; Thu, 05 Sep 2019 01:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IaZJ01VOJ44Z6Y9Qs3oUQiygt2Sy6fVI1ZsDthTYEac=; b=jMQkaaRRxSCpAfa0GGbTxN8sdW3BCz1aSdR6b+EoXx/Ue0KZCOzdiDMjAbfR7+eunv kx6XBxSzt7twCIJybPMD0h4eaU9yCitmULNsKZtsM1dUaTLn0IRFZwSO/spnqaAIn/WK smp1BnN01ssm7CCtza47yOcSEOeIXZ1ZULlSTfRZOEsNqdrJ7B42GvgGl8dAkW5Gxttk u9esLSmQOOsONHcK/RUZ141vgbuInB0YtTAbMwB/kfkNXGOaqNn3qNIWIPfg6k2EvkkU XJaDvfUoQwhTXwEmZVrsd8airEaBOdhwLNIkte996VruPPflokhLzMWXcXhvYQ73j8Px FatA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IaZJ01VOJ44Z6Y9Qs3oUQiygt2Sy6fVI1ZsDthTYEac=; b=SSCqe9qdyMympf5fHGRqs4AyjjxEim8eJtEII+Ac2T4FVeteMlMieIWR493rwfaNn0 zMUcX+XZAgbM9SpUr/qaAX0RhV2XNtOhc4Nc17ijoFzzuQjFQuC6uaBnt73N+HkH7lYg CqjE+CeebkJOlYD40ieYhOWmgzP8hrotU2gitwICtTZfW5AbXeLaMau0Z66lTvL+YGrq 41duMtPQjhqxKIzFOBM1iQA6WU9gwskPtoOyn+thO4m79bd/8TLl9wKMLglOQL2dZZ09 0R6b0kTPbTywjyTjknKuwbusrX6fSSViGKYRdryetYZUkB3SDGAM1nuphKL2qfTI60q9 S+0g== X-Gm-Message-State: APjAAAXWRlDA20xmTXGP6J2NW9Uf2rwyEVWOfq0t59r3ZhLPX0u02m12 SEO7+T3HH/xvzfVBAREKqlWK1pg3qwvJSOIQsf14rg== X-Google-Smtp-Source: APXvYqwoy7MTqB4H3mDdtS3aRDNvVJhhOoQARzpS77k98EfHG9CbyovynxJ3OmaOX9n7dO2thM4lg6LAw11dh4CzMMw= X-Received: by 2002:aca:f54d:: with SMTP id t74mr1740404oih.170.1567673816212; Thu, 05 Sep 2019 01:56:56 -0700 (PDT) MIME-Version: 1.0 References: <20190904180736.29009-1-xypron.glpk@gmx.de> <86r24vrwyh.wl-maz@kernel.org> <86mufjrup7.wl-maz@kernel.org> In-Reply-To: <86mufjrup7.wl-maz@kernel.org> From: Peter Maydell Date: Thu, 5 Sep 2019 09:56:44 +0100 Message-ID: Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded To: Marc Zyngier X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190905_015657_654215_2A462A96 X-CRM114-Status: GOOD ( 16.95 ) 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?Q?Daniel_P_=2E_Berrang=C3=A9?= , 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, 5 Sep 2019 at 09:52, Marc Zyngier wrote: > > On Thu, 05 Sep 2019 09:16:54 +0100, > Peter Maydell wrote: > > 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). Right, but the combination of "host kernel prints a message about an unsupported load/store insn" and "within-guest debug dump/stack trace/etc" is much more useful than just having "host kernel prints message" and "QEMU exits"; and it requires about 3 lines of code change... > 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. ...whereas this requires agreement on a kernel-userspace API, larger changes in the kernel, somebody to implement the userspace side of things, and the user to update both the kernel and QEMU. It's hard for me to see that the benefit here over the 3-line approach really outweighs the extra effort needed. In practice saying "we should do this" is saying "we're going to do nothing", based on the historical record. thanks -- PMM _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel