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.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 F0826C43331 for ; Fri, 6 Sep 2019 13:41:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C055020650 for ; Fri, 6 Sep 2019 13:41:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=amazon.com header.i=@amazon.com header.b="V103KYjn" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393347AbfIFNlb (ORCPT ); Fri, 6 Sep 2019 09:41:31 -0400 Received: from smtp-fw-4101.amazon.com ([72.21.198.25]:49334 "EHLO smtp-fw-4101.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732512AbfIFNla (ORCPT ); Fri, 6 Sep 2019 09:41:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1567777289; x=1599313289; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=XMIKAY1xJL7NYmAZNKLAmXbXU9LqB+oBH7gwXT7mxi8=; b=V103KYjnlek9k+nL+OVEjDwuZdjOUKzrO7ByegAxEQKVOm42LtsYvtP3 lXtO6IOeT223cMU8QZzIQ1Um0sHXjjGdeGlbBpP7YAjBprowS5UkW/4Qp 5VShguIqxbuW+n6jUwLtiG0vRh/1CTThdgTgHMR0xO6ZWZof+DT0tsOJg 8=; X-IronPort-AV: E=Sophos;i="5.64,473,1559520000"; d="scan'208";a="783639180" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2b-8cc5d68b.us-west-2.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP; 06 Sep 2019 13:41:26 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2b-8cc5d68b.us-west-2.amazon.com (Postfix) with ESMTPS id 5EB25A17B2; Fri, 6 Sep 2019 13:41:25 +0000 (UTC) Received: from EX13D20UWC001.ant.amazon.com (10.43.162.244) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 6 Sep 2019 13:41:24 +0000 Received: from 38f9d3867b82.ant.amazon.com (10.43.162.218) by EX13D20UWC001.ant.amazon.com (10.43.162.244) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 6 Sep 2019 13:41:22 +0000 Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded To: Peter Maydell , Christoffer Dall CC: =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= , Marc Zyngier , lkml - Kernel Mailing List , Stefan Hajnoczi , Heinrich Schuchardt , , arm-mail-list References: <20190904180736.29009-1-xypron.glpk@gmx.de> <86r24vrwyh.wl-maz@kernel.org> <86mufjrup7.wl-maz@kernel.org> <20190905092223.GC4320@e113682-lin.lund.arm.com> <4b6662bd-56e4-3c10-3b65-7c90828a22f9@kernel.org> <20190906080033.GF4320@e113682-lin.lund.arm.com> <20190906131252.GG4320@e113682-lin.lund.arm.com> From: Alexander Graf Message-ID: <28c5c021-7cb0-616b-4215-dd75242c16e6@amazon.com> Date: Fri, 6 Sep 2019 15:41:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Originating-IP: [10.43.162.218] X-ClientProxiedBy: EX13D16UWB004.ant.amazon.com (10.43.161.170) To EX13D20UWC001.ant.amazon.com (10.43.162.244) Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: base64 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org CgpPbiAwNi4wOS4xOSAxNTozMSwgUGV0ZXIgTWF5ZGVsbCB3cm90ZToKPiBPbiBGcmksIDYgU2Vw IDIwMTkgYXQgMTQ6MTMsIENocmlzdG9mZmVyIERhbGwgPGNocmlzdG9mZmVyLmRhbGxAYXJtLmNv bT4gd3JvdGU6Cj4+IEknZCBwcmVmZXIgbGVhdmluZyBpdCB0byB1c2Vyc3BhY2UgdG8gd29ycnkg YWJvdXQsIGJ1dCBJIHRob3VnaHQgUGV0ZXIKPj4gc2FpZCB0aGF0IGhhZCBiZWVuIHByb2JsZW1h dGljIGhpc3RvcmljYWxseSwgd2hpY2ggSSB0b29rIGF0IGZhY2UgdmFsdWUsCj4+IGJ1dCBJIGNv dWxkIGhhdmUgbWlzdW5kZXJzdG9vZC4KPj4KPj4gSWYgUUVNVSwga3ZtdG9vbCwgYW5kIHdoYXRl dmVyIHRoZSBjcmF6eV5IIGNvb2wga2lkcyBhcmUgdXNpbmcgaW4KPj4gdXNlcnNwYWNlIHRoZXNl IGRheXMgYXJlIGhhcHB5IGVtdWxhdGluZyB0aGUgZXhjZXB0aW9uLCB0aGVuIHRoYXQncyBhCj4+ IHZpYWJsZSBhcHByb2FjaC4gIFRoZSBtYWluIGNvbmNlcm4gSSBoYXZlIHdpdGggdGhhdCBpcyB3 aGV0aGVyIHRoZXknbGwKPj4gYWxsIGdldCBpdCByaWdodCwgYW5kIHNpbmNlIHdlIGFscmVhZHkg aGF2ZSB0aGUgY29kZSBpbiB0aGUga2VybmVsIHRvIGRvCj4+IHRoaXMsIGl0IG1pZ2h0IG1ha2Ug c2Vuc2UgdG8gcmUtdXNlIHRoZSBrZXJuZWwgbG9naWMgZm9yIGl0Lgo+IAo+IFdlbGwsIGZvciBR RU1VIHdlJ3ZlIGhhZCBjb2RlIHRoYXQgaW4gdGhlb3J5IG1pZ2h0IGRvIHRoaXMgYnV0Cj4gaW4g cHJhY3RpY2UgaXQncyBuZXZlciBiZWVuIHRlc3RlZC4gRXNzZW50aWFsbHkgdGhlIHByb2JsZW0g aXMKPiB0aGF0IG5vYm9keSBldmVyIHdhbnRzIHRvIGluamVjdCBhbiBleGNlcHRpb24gZnJvbSB1 c2Vyc3BhY2UKPiBleGNlcHQgaW4gaW5jcmVkaWJseSByYXJlIGNhc2VzIGxpa2UgInRyeWluZyB0 byB1c2UgaC93IGJyZWFrcG9pbnRzCj4gc2ltdWx0YW5lb3VzbHkgaW5zaWRlIHRoZSBWTSBhbmQg YWxzbyB0byBkZWJ1ZyB0aGUgVk0gZnJvbSBvdXRzaWRlIgo+IG9yICJ3ZSdyZSBydW5uaW5nIG9u IFJBUyBoYXJkd2FyZSB0aGF0IGp1c3QgdG9sZCB1cyB0aGF0IHRoZSBWTSdzCj4gUkFNIHdhcyBm YXVsdHkiLiBUaGVyZSdzIG5vIGV2ZW4gdmFndWVseSBjb21tb25seS11c2VkIHVzZWNhc2UKPiBm b3IgaXQgdG9kYXk7IGFuZCB0aGlzIEFCSSBzdWdnZXN0aW9uIGFkZHMgYW5vdGhlciAidGhpcyBp cyBpbgo+IHByYWN0aWNlIGFsbW9zdCBuZXZlciBnb2luZyB0byBoYXBwZW4iIGNhc2UgdG8gdGhl IHBpbGUuIFRoZQo+IGNvZGVwYXRoIGlzIHVucmVsaWFibGUgaW4gUUVNVSBiZWNhdXNlIChhKSBp dCByZXF1aXJlcyBnZXR0aW5nCj4gc3luY2luZyBvZiBzeXNyZWcgdmFsdWVzIHRvIGFuZCBmcm9t IHRoZSBrZXJuZWwgcmlnaHQgLS0gdGhpcyBpcwo+IGFib3V0IHRoZSBvbmx5IHNpdHVhdGlvbiB3 aGVyZSB1c2Vyc3BhY2Ugd2FudHMgdG8gbW9kaWZ5IHN5c3JlZ3MKPiBkdXJpbmcgZXhlY3V0aW9u IG9mIHRoZSBWTSwgYXMgb3Bwb3NlZCB0byBqdXN0IHJlYWRpbmcgdGhlbSAtLSBhbmQKPiAoYikg d2UgdHJ5IHRvIHJldXNlIHRoZSBjb2RlIHdlIGFscmVhZHkgaGF2ZSB0aGF0IGRvZXMgVENHIGV4 Y2VwdGlvbgo+IGluamVjdGlvbiwgd2hpY2ggbWlnaHQgb3IgbWlnaHQgbm90IGJlIGEgZGVzaWdu IG1pc3Rha2UsIGFuZAoKVGhhdCdzIHByb2JhYmx5IGEgZGVzaWduIG1pc3Rha2UsIGNvcnJlY3Qg OikKCj4gKGMpIGFzIG5vdGVkIGFib3ZlIGl0J3MgYSBuZXZlci1hY3R1YWxseS11c2VkIHVudGVz dGVkIGNvZGVwYXRoLi4uCgpTb3VuZHMgbGlrZSBhbiBlYXN5IHRoaW5nIHRvIHJlc29sdmUgdXNp bmcga3ZtLXVuaXQtdGVzdHM/Cgo+IFNvIEkgdGhpbmsgaWYgSSB3ZXJlIHlvdSBJIHdvdWxkbid0 IGNvbW1pdCB0byB0aGUga2VybmVsIEFCSSB1bnRpbAo+IHNvbWVib2R5IGhhZCBhdCBsZWFzdCB3 cml0dGVuIHNvbWUgUkZDLXF1YWxpdHkgcGF0Y2hlcyBmb3IgUUVNVSBhbmQKPiB0ZXN0ZWQgdGhh dCB0aGV5IHdvcmsgYW5kIHRoZSBBQkkgaXMgT0sgaW4gdGhhdCBzZW5zZS4gKEZvciB0aGUKPiBh dm9pZGFuY2Ugb2YgZG91YnQsIEknbSBub3Qgdm9sdW50ZWVyaW5nIHRvIGRvIHRoYXQgbXlzZWxm LikKPiBJIGRvbid0IG9iamVjdCB0byB0aGUgaWRlYSBpbiBwcmluY2lwbGUsIHRob3VnaC4KPiAK PiBQUzogdGhlIG90aGVyICJpbmplY3RpbmcgZXhjZXB0aW9ucyB0byB0aGUgZ3Vlc3QiIG9kZGl0 eSBpcyB0aGF0Cj4gaWYgdGhlIGtlcm5lbCAqZG9lcyogZmluZCB0aGUgSVNWIGluZm9ybWF0aW9u IGFuZCByZXR1cm5zIHRvIHVzZXJzcGFjZQo+IGZvciBpdCB0byBoYW5kbGUgdGhlIE1NSU8sIHRo ZXJlJ3Mgbm8gd2F5IGZvciB1c2Vyc3BhY2UgdG8gc2F5Cj4gImFjdHVhbGx5IHRoYXQgYWRkcmVz cyBpcyBzdXBwb3NlZCB0byBnZW5lcmF0ZSBhIGRhdGEgYWJvcnQiLgoKSSB0aGluayB3ZSdyZSBj b252ZXJnaW5nIGhlcmUuIE15IHByb3Bvc2FsIGlzIHRoYXQgImluamVjdCBhIGZhdWx0IiAKc2hv dWxkIG5vdCBiZSBzb21ldGhpbmcgc3BlY2lhbCBjYXNlZCBmb3IgdGhlICJJIGNhbid0IGRlY29k ZSB0aGUgCmluc3RydWN0aW9uIiBjYXNlLCBidXQgcmF0aGVyIHRoYXQgd2UgbmVlZCBhIG1vcmUg Z2VuZXJpYyBtZWNoYW5pc20uCgpXaGV0aGVyIHRoYXQncyBhIG5ldyBpb2N0bCwgYSBmbGFnIHdl IHNldCBvbiBlbnRyeSBvciBzb21ldGhpbmcgZWxzZSBpcyAKYW4gaW1wbGVtZW50YXRpb24gZGV0 YWlsIEknbGwgYmUgaGFwcHkgdG8gbGVhdmUgZm9yIGRpc2N1c3Npb24uCgpUaGUgb25seSB0aGlu ZyBJJ2QgbGlrZSB0byBhdm9pZCBzZWVpbmcgaXMgdGhhdCB3ZSBjcmVhdGUgYSBuZXcgdXNlciAK c3BhY2UgQUJJIHRoYXQgbWFrZXMgaXQgZWFzeSB0byBpbmplY3QgYSBzaW5nbGUsIHBhcnRpY3Vs YXIgZXhjZXB0aW9uLCAKYnV0IG5vdCBzb2x2ZSBhbGwgb2YgdGhlIG90aGVyIGNhc2VzIHdoaWxl IGNyZWF0aW5nIGV4dHJhIHdvcmsgdG8ganVzdCAKaW1wbGVtZW50IGluc3RydWN0aW9uIGRlY29k aW5nIGluIHVzZXIgc3BhY2UuCgoKQWxleAoKCgpBbWF6b24gRGV2ZWxvcG1lbnQgQ2VudGVyIEdl cm1hbnkgR21iSApLcmF1c2Vuc3RyLiAzOAoxMDExNyBCZXJsaW4KR2VzY2hhZWZ0c2Z1ZWhydW5n OiBDaHJpc3RpYW4gU2NobGFlZ2VyLCBSYWxmIEhlcmJyaWNoCkVpbmdldHJhZ2VuIGFtIEFtdHNn ZXJpY2h0IENoYXJsb3R0ZW5idXJnIHVudGVyIEhSQiAxNDkxNzMgQgpTaXR6OiBCZXJsaW4KVXN0 LUlEOiBERSAyODkgMjM3IDg3OQoKCg== 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.9 required=3.0 tests=DKIM_ADSP_ALL,DKIM_INVALID, DKIM_SIGNED,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 2987BC43331 for ; Fri, 6 Sep 2019 13:41:38 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id A5F1320842 for ; Fri, 6 Sep 2019 13:41:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=amazon.com header.i=@amazon.com header.b="V103KYjn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A5F1320842 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=amazon.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 279F74A557; Fri, 6 Sep 2019 09:41:37 -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=@amazon.com 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 K04b0J2ZRvUX; Fri, 6 Sep 2019 09:41:34 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id BCA5D4A5BB; Fri, 6 Sep 2019 09:41:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C84534A568 for ; Fri, 6 Sep 2019 09:41:33 -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 knrMNjkHf0pt for ; Fri, 6 Sep 2019 09:41:31 -0400 (EDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 9CC7A4A5BA for ; Fri, 6 Sep 2019 09:41:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1567777289; x=1599313289; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=XMIKAY1xJL7NYmAZNKLAmXbXU9LqB+oBH7gwXT7mxi8=; b=V103KYjnlek9k+nL+OVEjDwuZdjOUKzrO7ByegAxEQKVOm42LtsYvtP3 lXtO6IOeT223cMU8QZzIQ1Um0sHXjjGdeGlbBpP7YAjBprowS5UkW/4Qp 5VShguIqxbuW+n6jUwLtiG0vRh/1CTThdgTgHMR0xO6ZWZof+DT0tsOJg 8=; X-IronPort-AV: E=Sophos;i="5.64,473,1559520000"; d="scan'208";a="783639180" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2b-8cc5d68b.us-west-2.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP; 06 Sep 2019 13:41:26 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2b-8cc5d68b.us-west-2.amazon.com (Postfix) with ESMTPS id 5EB25A17B2; Fri, 6 Sep 2019 13:41:25 +0000 (UTC) Received: from EX13D20UWC001.ant.amazon.com (10.43.162.244) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 6 Sep 2019 13:41:24 +0000 Received: from 38f9d3867b82.ant.amazon.com (10.43.162.218) by EX13D20UWC001.ant.amazon.com (10.43.162.244) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 6 Sep 2019 13:41:22 +0000 Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded To: Peter Maydell , Christoffer Dall References: <20190904180736.29009-1-xypron.glpk@gmx.de> <86r24vrwyh.wl-maz@kernel.org> <86mufjrup7.wl-maz@kernel.org> <20190905092223.GC4320@e113682-lin.lund.arm.com> <4b6662bd-56e4-3c10-3b65-7c90828a22f9@kernel.org> <20190906080033.GF4320@e113682-lin.lund.arm.com> <20190906131252.GG4320@e113682-lin.lund.arm.com> From: Alexander Graf Message-ID: <28c5c021-7cb0-616b-4215-dd75242c16e6@amazon.com> Date: Fri, 6 Sep 2019 15:41:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Originating-IP: [10.43.162.218] X-ClientProxiedBy: EX13D16UWB004.ant.amazon.com (10.43.161.170) To EX13D20UWC001.ant.amazon.com (10.43.162.244) Precedence: Bulk Cc: =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= , 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 List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On 06.09.19 15:31, Peter Maydell wrote: > On Fri, 6 Sep 2019 at 14:13, Christoffer Dall wrote: >> I'd prefer leaving it to userspace to worry about, but I thought Peter >> said that had been problematic historically, which I took at face value, >> but I could have misunderstood. >> >> If QEMU, kvmtool, and whatever the crazy^H cool kids are using in >> userspace these days are happy emulating the exception, then that's a >> viable approach. The main concern I have with that is whether they'll >> all get it right, and since we already have the code in the kernel to do >> this, it might make sense to re-use the kernel logic for it. > > Well, for QEMU we've had code that in theory might do this but > in practice it's never been tested. Essentially the problem is > that nobody ever wants to inject an exception from userspace > except in incredibly rare cases like "trying to use h/w breakpoints > simultaneously inside the VM and also to debug the VM from outside" > or "we're running on RAS hardware that just told us that the VM's > RAM was faulty". There's no even vaguely commonly-used usecase > for it today; and this ABI suggestion adds another "this is in > practice almost never going to happen" case to the pile. The > codepath is unreliable in QEMU because (a) it requires getting > syncing of sysreg values to and from the kernel right -- this is > about the only situation where userspace wants to modify sysregs > during execution of the VM, as opposed to just reading them -- and > (b) we try to reuse the code we already have that does TCG exception > injection, which might or might not be a design mistake, and That's probably a design mistake, correct :) > (c) as noted above it's a never-actually-used untested codepath... Sounds like an easy thing to resolve using kvm-unit-tests? > So I think if I were you I wouldn't commit to the kernel ABI until > somebody had at least written some RFC-quality patches for QEMU and > tested that they work and the ABI is OK in that sense. (For the > avoidance of doubt, I'm not volunteering to do that myself.) > I don't object to the idea in principle, though. > > PS: the other "injecting exceptions to the guest" oddity is that > if the kernel *does* find the ISV information and returns to userspace > for it to handle the MMIO, there's no way for userspace to say > "actually that address is supposed to generate a data abort". I think we're converging here. My proposal is that "inject a fault" should not be something special cased for the "I can't decode the instruction" case, but rather that we need a more generic mechanism. Whether that's a new ioctl, a flag we set on entry or something else is an implementation detail I'll be happy to leave for discussion. The only thing I'd like to avoid seeing is that we create a new user space ABI that makes it easy to inject a single, particular exception, but not solve all of the other cases while creating extra work to just implement instruction decoding in user space. Alex Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 _______________________________________________ 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.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_ADSP_ALL, 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 326E8C43331 for ; Fri, 6 Sep 2019 13:41:40 +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 0A30320650 for ; Fri, 6 Sep 2019 13:41:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="kvToAKtK"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=amazon.com header.i=@amazon.com header.b="HM7+1Sr+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A30320650 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=amazon.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-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=l0TdL0qzr7PFswgxjbvbzCdNmKCRULz3cTR36fU1JV8=; b=kvToAKtKI7Yd3WzpD7qoSoWD7 w9RuWaJ0wUlVc1QnkerDDIVK1dko3pH7eRlbxHyfUVOc9AxALGpOxFU8ipsZZMLi6JnULFuLTOQ5j eKTpBeg2Y60SqVEpbCdLsf8gTC5/ypnDwhBj9XpX8hbzzmf53Lt0TI4nh7F1eewlta7jePmIagxaW tMpjCAUlXHT41oAeK7dIwj4fbpSypB5BN2hwcUDlkBUsIwVGcNMUPuOh6Go0UBtEyZiAQF5qv4l2j FoFq9RM60IOvNWTpDagI1vfqqt4bJp/qCP143jDVf8j0GjXDGkJ9tlmBantMXg4vzwSDZ21iib7KN 2sHYVrRpg==; 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 1i6EUX-0002zj-TI; Fri, 06 Sep 2019 13:41:33 +0000 Received: from smtp-fw-4101.amazon.com ([72.21.198.25]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1i6EUU-0002zC-Ta for linux-arm-kernel@lists.infradead.org; Fri, 06 Sep 2019 13:41:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1567777290; x=1599313290; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=XMIKAY1xJL7NYmAZNKLAmXbXU9LqB+oBH7gwXT7mxi8=; b=HM7+1Sr+zDwdmUIPSDV0hG0nu8jjWkBaY4cw+WdQfgWazhVsV0vVlZUq Hj1iGwHIlhF1YcTkDy3TOS5/WvbZ6s7EYIeNynT6JhX7Eu+hejFmr8/S/ JPE4HS/SpZEDBbiO/G2FXMyeo37lzbbHyYzEXnOcJgo0kDc93B0dywH7+ M=; X-IronPort-AV: E=Sophos;i="5.64,473,1559520000"; d="scan'208";a="783639180" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2b-8cc5d68b.us-west-2.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP; 06 Sep 2019 13:41:26 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2b-8cc5d68b.us-west-2.amazon.com (Postfix) with ESMTPS id 5EB25A17B2; Fri, 6 Sep 2019 13:41:25 +0000 (UTC) Received: from EX13D20UWC001.ant.amazon.com (10.43.162.244) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 6 Sep 2019 13:41:24 +0000 Received: from 38f9d3867b82.ant.amazon.com (10.43.162.218) by EX13D20UWC001.ant.amazon.com (10.43.162.244) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 6 Sep 2019 13:41:22 +0000 Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded To: Peter Maydell , Christoffer Dall References: <20190904180736.29009-1-xypron.glpk@gmx.de> <86r24vrwyh.wl-maz@kernel.org> <86mufjrup7.wl-maz@kernel.org> <20190905092223.GC4320@e113682-lin.lund.arm.com> <4b6662bd-56e4-3c10-3b65-7c90828a22f9@kernel.org> <20190906080033.GF4320@e113682-lin.lund.arm.com> <20190906131252.GG4320@e113682-lin.lund.arm.com> From: Alexander Graf Message-ID: <28c5c021-7cb0-616b-4215-dd75242c16e6@amazon.com> Date: Fri, 6 Sep 2019 15:41:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Originating-IP: [10.43.162.218] X-ClientProxiedBy: EX13D16UWB004.ant.amazon.com (10.43.161.170) To EX13D20UWC001.ant.amazon.com (10.43.162.244) Precedence: Bulk X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190906_064131_154514_384CE2F0 X-CRM114-Status: GOOD ( 23.06 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= , Marc Zyngier , lkml - Kernel Mailing List , Stefan Hajnoczi , Heinrich Schuchardt , kvmarm@lists.cs.columbia.edu, arm-mail-list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 06.09.19 15:31, Peter Maydell wrote: > On Fri, 6 Sep 2019 at 14:13, Christoffer Dall wrote: >> I'd prefer leaving it to userspace to worry about, but I thought Peter >> said that had been problematic historically, which I took at face value, >> but I could have misunderstood. >> >> If QEMU, kvmtool, and whatever the crazy^H cool kids are using in >> userspace these days are happy emulating the exception, then that's a >> viable approach. The main concern I have with that is whether they'll >> all get it right, and since we already have the code in the kernel to do >> this, it might make sense to re-use the kernel logic for it. > > Well, for QEMU we've had code that in theory might do this but > in practice it's never been tested. Essentially the problem is > that nobody ever wants to inject an exception from userspace > except in incredibly rare cases like "trying to use h/w breakpoints > simultaneously inside the VM and also to debug the VM from outside" > or "we're running on RAS hardware that just told us that the VM's > RAM was faulty". There's no even vaguely commonly-used usecase > for it today; and this ABI suggestion adds another "this is in > practice almost never going to happen" case to the pile. The > codepath is unreliable in QEMU because (a) it requires getting > syncing of sysreg values to and from the kernel right -- this is > about the only situation where userspace wants to modify sysregs > during execution of the VM, as opposed to just reading them -- and > (b) we try to reuse the code we already have that does TCG exception > injection, which might or might not be a design mistake, and That's probably a design mistake, correct :) > (c) as noted above it's a never-actually-used untested codepath... Sounds like an easy thing to resolve using kvm-unit-tests? > So I think if I were you I wouldn't commit to the kernel ABI until > somebody had at least written some RFC-quality patches for QEMU and > tested that they work and the ABI is OK in that sense. (For the > avoidance of doubt, I'm not volunteering to do that myself.) > I don't object to the idea in principle, though. > > PS: the other "injecting exceptions to the guest" oddity is that > if the kernel *does* find the ISV information and returns to userspace > for it to handle the MMIO, there's no way for userspace to say > "actually that address is supposed to generate a data abort". I think we're converging here. My proposal is that "inject a fault" should not be something special cased for the "I can't decode the instruction" case, but rather that we need a more generic mechanism. Whether that's a new ioctl, a flag we set on entry or something else is an implementation detail I'll be happy to leave for discussion. The only thing I'd like to avoid seeing is that we create a new user space ABI that makes it easy to inject a single, particular exception, but not solve all of the other cases while creating extra work to just implement instruction decoding in user space. Alex Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel