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 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 C890EC3A5A5 for ; Thu, 5 Sep 2019 08:17:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9F7AA21743 for ; Thu, 5 Sep 2019 08:17:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="OuTz5wvU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731881AbfIEIRG (ORCPT ); Thu, 5 Sep 2019 04:17:06 -0400 Received: from mail-ot1-f65.google.com ([209.85.210.65]:46958 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730937AbfIEIRG (ORCPT ); Thu, 5 Sep 2019 04:17:06 -0400 Received: by mail-ot1-f65.google.com with SMTP id g19so1260252otg.13 for ; Thu, 05 Sep 2019 01:17:06 -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=0xPzSESc4AZSzOz8iuenGzI1AlT1OxyaOVK/bXB62NU=; b=OuTz5wvUQ35QYkpSKKPCxxQaaU1HK9r2e88MGLbbYqoqxReti2Duuk8kuS0KYSC1Ip pdHLMs7zhO419UJhHXlo+5eiLjxOlJzvBJvCkJ3krsKonpbm0VX4vie2pR8FyWB7NvC8 xwNADNZ++jqxlZ73zV3Fv4RHQ1CtN/gCiJYwY6zC+I9oUFbUzixbhoF1ofdOq8nGsV/x zsdighpHoFIa+hFO9Gfuw4SI4cNG/br0SpICPLmLwP7JT0b8Rw1es+25pX61XTWttPNd pNvFwcXfQACkPtI8sYYB2mxINaHDTZiPwLrnEMjPnV1KdzshSBt/8xJLmUURA816hh65 xaDg== 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=0xPzSESc4AZSzOz8iuenGzI1AlT1OxyaOVK/bXB62NU=; b=XDIm8UwLNyHxhlTc7uvTfWNWAkL11RxpARXh4f+miUc+NoPWc2ZoLfLqetz4uxJMJE dwz9KCBq07uWB0X6wUZwnqDFnApOD+9y/ccjqALCKsTm7lnhaPxkFv1d/V510w5Nexk3 O/y/tmlswHx+4zgrjUf70iPhVgvzpxjuARXhNMBKYrEiepv7R2KCeOpYmbgrZVH3b0Nm ihTITPhwIPQPe0KYyVeLj5gkvFBEC4mWFDG5C00+yD20++aTnE5qQCtN87AqnSSro8zZ PddLlA2QDo/QfxXHMsBeF4MH/Eh5rvrrEs7H5xDlilDbQs7C6BFaDsPj9FfUWnAvYrNY F1CQ== X-Gm-Message-State: APjAAAVm/QPJGb+UaL+NJVtpz0lEYqoYmVN/38GtRkr7gHBQNfDJOW2a i+5wlNp8GEcrQV3pM3/DLYSZvgsxuf2c10W2JQz/lg== X-Google-Smtp-Source: APXvYqy24rjXe/FVSgFiU9SxJ4vZK2hJu//H06XcbxMiz2ueKtSmAR0GsP61bsSotW7CRw5je/6qibK/HvRFMTwLvZ0= X-Received: by 2002:a9d:5e11:: with SMTP id d17mr1498113oti.135.1567671425605; Thu, 05 Sep 2019 01:17:05 -0700 (PDT) MIME-Version: 1.0 References: <20190904180736.29009-1-xypron.glpk@gmx.de> <86r24vrwyh.wl-maz@kernel.org> In-Reply-To: <86r24vrwyh.wl-maz@kernel.org> From: Peter Maydell Date: Thu, 5 Sep 2019 09:16:54 +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: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... 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.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,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 91DA7C3A5A5 for ; Thu, 5 Sep 2019 08:17: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 1334021743 for ; Thu, 5 Sep 2019 08:17:09 +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="OuTz5wvU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1334021743 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 76D1C4A521; Thu, 5 Sep 2019 04:17:09 -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 4RdPIy1fO2Kt; Thu, 5 Sep 2019 04:17:08 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6E5D14A581; Thu, 5 Sep 2019 04:17:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4569C4A558 for ; Thu, 5 Sep 2019 04:17:07 -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 KTDdaVWR1Ozs for ; Thu, 5 Sep 2019 04:17:06 -0400 (EDT) Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 23B4F4A521 for ; Thu, 5 Sep 2019 04:17:06 -0400 (EDT) Received: by mail-ot1-f65.google.com with SMTP id n7so1302990otk.6 for ; Thu, 05 Sep 2019 01:17:06 -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=0xPzSESc4AZSzOz8iuenGzI1AlT1OxyaOVK/bXB62NU=; b=OuTz5wvUQ35QYkpSKKPCxxQaaU1HK9r2e88MGLbbYqoqxReti2Duuk8kuS0KYSC1Ip pdHLMs7zhO419UJhHXlo+5eiLjxOlJzvBJvCkJ3krsKonpbm0VX4vie2pR8FyWB7NvC8 xwNADNZ++jqxlZ73zV3Fv4RHQ1CtN/gCiJYwY6zC+I9oUFbUzixbhoF1ofdOq8nGsV/x zsdighpHoFIa+hFO9Gfuw4SI4cNG/br0SpICPLmLwP7JT0b8Rw1es+25pX61XTWttPNd pNvFwcXfQACkPtI8sYYB2mxINaHDTZiPwLrnEMjPnV1KdzshSBt/8xJLmUURA816hh65 xaDg== 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=0xPzSESc4AZSzOz8iuenGzI1AlT1OxyaOVK/bXB62NU=; b=hhHgI2qRbmt8SV4ZNYv/xD7Xf/M0GOlfiapoEsjmqRbKIZz9LnTw4W5kvC66ji6deL mALyVmsYZd26dDXDTjhiZyZDjrWl7LEPKQBmhrklEz02FGtSsNrzuFKzvZLga016VflA 8l//clvPZAFsPkcm+7GdIZC1H43eCnJg4T8owZ1hq3F+mb7TFCbHFNH4bfdO/3s6PfSd RPmZSKmhDGpJKAsQZermjEN91ox3khYxphhc0xkEHyD9MuTAct2012j4ARI7rSKnKTRa dPgr4QNP2JhBaOMJpyt5UluHDQWl1aZFTU2vhkjB3jfwoXgbl+tn3tNb24kTWX+/Z2fC b+4A== X-Gm-Message-State: APjAAAUFWW2frsPRoihquyQOMAjnQjxa7ErPpG/ByJfbg01HfP/vqe0v Iiz43yK0cQhGTH8ohpgjcy/w01rC8guiiw3/gUuY/Q== X-Google-Smtp-Source: APXvYqy24rjXe/FVSgFiU9SxJ4vZK2hJu//H06XcbxMiz2ueKtSmAR0GsP61bsSotW7CRw5je/6qibK/HvRFMTwLvZ0= X-Received: by 2002:a9d:5e11:: with SMTP id d17mr1498113oti.135.1567671425605; Thu, 05 Sep 2019 01:17:05 -0700 (PDT) MIME-Version: 1.0 References: <20190904180736.29009-1-xypron.glpk@gmx.de> <86r24vrwyh.wl-maz@kernel.org> In-Reply-To: <86r24vrwyh.wl-maz@kernel.org> From: Peter Maydell Date: Thu, 5 Sep 2019 09:16:54 +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: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... 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 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 2557BC3A5A5 for ; Thu, 5 Sep 2019 08:17:33 +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 DD3D320828 for ; Thu, 5 Sep 2019 08:17:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="lZu6bR3U"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="OuTz5wvU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DD3D320828 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=8o3zFMK3+V2rwPiFea7nDN9UX9AR/XyLUC3zRyPBGUk=; b=lZu6bR3UgynIrD teNyoTZcwl9O9hAEYU1wrHB05HD10WsqnlD23m/8avHP+fMutC80jhv7Sda8o5FRjJ1Va4q0hblnZ 6MPLXu0sYUoXJbgnXSfR7QYUBGZ6nETsQhRZDSxeqlVbryM4hBO+ZC0kSUXO98f8rx7wYKph7+pmz 3/M7QuH8neBQUZG+OlnkV9zPabuZbT431N42bYwNjg131DlrQx2v1Uq8a97CeXTWThIgVkkd2u2dM LHZiOC53mHBytXOlMQtjQwfwwWDfBfhb/3CgvnepNa57VIS8Ck7UEsDW5WPTbjfe8ySSA+ZtdDnhZ pZxwNvSmBWb18s7eFq5A==; 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 1i5mxN-0001ME-VF; Thu, 05 Sep 2019 08:17:30 +0000 Received: from mail-ot1-x342.google.com ([2607:f8b0:4864:20::342]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1i5mx0-00014r-TH for linux-arm-kernel@lists.infradead.org; Thu, 05 Sep 2019 08:17:08 +0000 Received: by mail-ot1-x342.google.com with SMTP id y39so1297011ota.7 for ; Thu, 05 Sep 2019 01:17:06 -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=0xPzSESc4AZSzOz8iuenGzI1AlT1OxyaOVK/bXB62NU=; b=OuTz5wvUQ35QYkpSKKPCxxQaaU1HK9r2e88MGLbbYqoqxReti2Duuk8kuS0KYSC1Ip pdHLMs7zhO419UJhHXlo+5eiLjxOlJzvBJvCkJ3krsKonpbm0VX4vie2pR8FyWB7NvC8 xwNADNZ++jqxlZ73zV3Fv4RHQ1CtN/gCiJYwY6zC+I9oUFbUzixbhoF1ofdOq8nGsV/x zsdighpHoFIa+hFO9Gfuw4SI4cNG/br0SpICPLmLwP7JT0b8Rw1es+25pX61XTWttPNd pNvFwcXfQACkPtI8sYYB2mxINaHDTZiPwLrnEMjPnV1KdzshSBt/8xJLmUURA816hh65 xaDg== 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=0xPzSESc4AZSzOz8iuenGzI1AlT1OxyaOVK/bXB62NU=; b=LE4tzLInL91ozrYKg/2Y5rF203Hwb32UIIh+Xv+lbNQv3nYJBs316hLh3HmlTDugqV uozZbdnel9LCXx1j+hufjAyY9duOHJhKqEWmlgX4QmPjgY4TlJkue4btsXgh0Gxk5Rf1 AEtvB/33isv4JDaUJZLl1SNUJ5WvImx2j6npn3Mncbjob3iZDb8+J0jRh5fWlZnAqjEk NVflGUw8T0yoj3g95i8aYpEQO+c6XZ14uloXAS1lBmqV2TY2/fP0XbAXiWaMjeWktgm8 vJXfbbJldaXvRKCtlxAjD9xsN9VezE1fBNZK0pWUS2V7YNRiocxBrSGI377g6x6OwZ8R I5TQ== X-Gm-Message-State: APjAAAUR6ytikJHGarvHR4tSMEMCi4MvZAraxUdXJT4hjVnme8JfjXZe TLTxp+WClum6BvCfJ5s0BDzznkF7C87rYQZjOptFxA== X-Google-Smtp-Source: APXvYqy24rjXe/FVSgFiU9SxJ4vZK2hJu//H06XcbxMiz2ueKtSmAR0GsP61bsSotW7CRw5je/6qibK/HvRFMTwLvZ0= X-Received: by 2002:a9d:5e11:: with SMTP id d17mr1498113oti.135.1567671425605; Thu, 05 Sep 2019 01:17:05 -0700 (PDT) MIME-Version: 1.0 References: <20190904180736.29009-1-xypron.glpk@gmx.de> <86r24vrwyh.wl-maz@kernel.org> In-Reply-To: <86r24vrwyh.wl-maz@kernel.org> From: Peter Maydell Date: Thu, 5 Sep 2019 09:16:54 +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_011707_063893_499336B9 X-CRM114-Status: GOOD ( 12.21 ) 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: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... thanks -- PMM _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel