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=-6.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,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 155C7C4363A for ; Mon, 26 Oct 2020 14:05:56 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 B4AEC2242A for ; Mon, 26 Oct 2020 14:05:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="hU970pfO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B4AEC2242A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=XlBpX5btsCJpPe3iUdK9KgTdkTfdLzQXnVbZXCc7W6k=; b=hU970pfOOOlt6hiNPotZud/2X unl1EKhZA4j8+eJxzRTe3vWn9+Gn/83PKH18HBKET5ljrZJe55i9xy9JHuM2/oDe1XCF1YCsxwVva FpbYEsMkdnyEeaPujMDSlCM6eVpzWiOKeA/lYxkcZLZhsiU5a2s87PPSEwl++QH7wbfPIIIJkGEsS TVfPYtLUS9AY/nQcBm7i7wV85XP+9iwB3Cw23ACa2EqKCfD/1ARsC5XMWryEbea2uVHsxxdP7n+IK g7resxM8ORAElYWuBSexsG8M2I71c0EgHVLT9CcRju/sGZhIYKzWqb2JF+6J1hoOePGRpi1y0t1W5 N7P6pt9Fw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kX376-0003gU-Jk; Mon, 26 Oct 2020 14:04:44 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kX373-0003fP-IK for linux-arm-kernel@lists.infradead.org; Mon, 26 Oct 2020 14:04:42 +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 894B230E; Mon, 26 Oct 2020 07:04:39 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.56.187]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 180C33F68F; Mon, 26 Oct 2020 07:04:37 -0700 (PDT) Date: Mon, 26 Oct 2020 14:04:35 +0000 From: Mark Rutland To: Marc Zyngier Subject: Re: [PATCH 03/11] KVM: arm64: Make kvm_skip_instr() and co private to HYP Message-ID: <20201026140435.GE12454@C02TD0UTHF1T.local> References: <20201026133450.73304-1-maz@kernel.org> <20201026133450.73304-4-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201026133450.73304-4-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201026_100441_732308_E0568E14 X-CRM114-Status: GOOD ( 15.78 ) 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: Will Deacon , kernel-team@android.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Oct 26, 2020 at 01:34:42PM +0000, Marc Zyngier wrote: > In an effort to remove the vcpu PC manipulations from EL1 on nVHE > systems, move kvm_skip_instr() to be HYP-specific. EL1's intent > to increment PC post emulation is now signalled via a flag in the > vcpu structure. > > Signed-off-by: Marc Zyngier [...] > +/* > + * Adjust the guest PC on entry, depending on flags provided by EL1 > + * for the purpose of emulation (MMIO, sysreg). > + */ > +static inline void __adjust_pc(struct kvm_vcpu *vcpu) > +{ > + if (vcpu->arch.flags & KVM_ARM64_INCREMENT_PC) { > + kvm_skip_instr(vcpu); > + vcpu->arch.flags &= ~KVM_ARM64_INCREMENT_PC; > + } > +} What's your plan for restricting *when* EL1 can ask for the PC to be adjusted? I'm assuming that either: 1. You have EL2 sanity-check all responses from EL1 are permitted for the current state. e.g. if EL1 asks to increment the PC, EL2 must check that that was a sane response for the current state. 2. You raise the level of abstraction at the EL2/EL1 boundary, such that EL2 simply knows. e.g. if emulating a memory access, EL1 can either provide the response or signal an abort, but doesn't choose to manipulate the PC as EL2 will infer the right thing to do. I know that either are tricky in practice, so I'm curious what your view is. Generally option #2 is easier to fortify, but I guess we might have to do #1 since we also have to support unprotected VMs? Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel