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 BD863C43331 for ; Fri, 6 Sep 2019 14:13:12 +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 9171F20842 for ; Fri, 6 Sep 2019 14:13:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="FN6kjWSZ"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=amazon.com header.i=@amazon.com header.b="JEjCBTwd" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9171F20842 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=NwxYYOQJ363cVBIY38kLItvyS8vvZvWwtf6AUHTpVtM=; b=FN6kjWSZE0NRGZ7FI3p9T9Qj+ yemvYcCgtjwDrmq3QFR0DMaChSfF6YFc7qMqGMq3ncX4HE47rHHS5isD9d6v6mfWCH5lqcBI4PIT1 lfNAD9+o0vdUSFXQVZDk94N0i7o+j+NtkJ0fMpZBlwc/FWBn/tFfMZnJlGYFGPw0DIzBTIFOzcX9Z nGXGpKqAyw/8QhMHhJUElzpx0pj1+GsO+Mfnqv002POglYtOSQkru8eOJSPkp6UKrMLdtaQy2kEnG rBkNWB2K/jW19b9TbdKXDvNgflErkGSo6yVhiQVR5faKpm0cIpfWgKBzlEiFa4MqJDXxvSegwQdwA ujFEeL2Rw==; 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 1i6Ez3-0007dV-Pm; Fri, 06 Sep 2019 14:13:06 +0000 Received: from smtp-fw-6001.amazon.com ([52.95.48.154]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1i6Ez0-0007d7-LL for linux-arm-kernel@lists.infradead.org; Fri, 06 Sep 2019 14:13:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1567779182; x=1599315182; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=9G4bFzovgTxqFaJRsXnATnhBOQd8Ab1q5goy+J25MD4=; b=JEjCBTwdSLij4ASmlw97hai+VR/fKDDhI+yxWBtPOy1P2pJc77XIalDT UKmODJ2mHdm0IgVzixBTTaeJz3Zjo4yZvIfKBXp1BtUgu+syzL7DOMZ10 TecSLPGlQlvkswdhtmq4ZLJCOflcBlsGDorJAJgmsgZ5xiWM1yvE1jddI k=; X-IronPort-AV: E=Sophos;i="5.64,473,1559520000"; d="scan'208";a="413941107" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1a-821c648d.us-east-1.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP; 06 Sep 2019 14:12:59 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1a-821c648d.us-east-1.amazon.com (Postfix) with ESMTPS id F40E0A2404; Fri, 6 Sep 2019 14:12:56 +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 14:12:56 +0000 Received: from 38f9d3867b82.ant.amazon.com (10.43.162.242) by EX13D20UWC001.ant.amazon.com (10.43.162.244) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 6 Sep 2019 14:12:53 +0000 Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded To: Peter Maydell 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> <28c5c021-7cb0-616b-4215-dd75242c16e6@amazon.com> From: Alexander Graf Message-ID: Date: Fri, 6 Sep 2019 16:12:51 +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.242] X-ClientProxiedBy: EX13D18UWC003.ant.amazon.com (10.43.162.237) 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_071302_906720_96A5067D X-CRM114-Status: GOOD ( 13.36 ) 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?= , Heinrich Schuchardt , Christoffer Dall , lkml - Kernel Mailing List , Stefan Hajnoczi , Marc Zyngier , 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:50, Peter Maydell wrote: > On Fri, 6 Sep 2019 at 14:41, Alexander Graf wrote: >> On 06.09.19 15:31, Peter Maydell wrote: >>> (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 :) > > Well, conceptually it's not necessarily a bad idea, because > in both cases what we're doing is "change the system register > state (PC, ESR_EL1, ELR_EL1 etc) so that the CPU looks like > it's just taken an exception"; but some of what the > TCG code needs to do isn't necessary for KVM and all of it > was not written with the idea of KVM in mind at all... Yes, and it probably makes sense to model the QEMU internal API similarly, so that exception generating code does not have to distinguish. However, it's much easier for KVM to ensure exception prioritization as well as internal state synchronization. Conceptually, as you've seen, it really doesn't make a lot of sense to pull register state from KVM, wiggle it and then push it down when KVM has awareness of the same transformation anyway. So I guess the path is clear: Create a generic interface for exception injection and a separate patch similar to what Christoffer already posted with the new CAP to route illegal MMIO traps into user space. Connecting the two dots in user space really should be trivial then. (famous last words) 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