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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 4707FC04A68 for ; Wed, 27 Jul 2022 10:44:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=x4CPDxmKMi4nZB6JKV+5rWFuaIMuMrRbN0AMG4zZIgI=; b=Kb2Z2ZrJKLZdfL e/8YvUfyQGJ/pz7viF+kRFWhW/KZBCkzOLFcIpGsgO6FlmWqkn49KIv5h5pTMbEBAzO7dOSeH/AJZ 6RBSola06hzEUPPPZ66ftmaHSVT+S1GDZCKeLaJXeR790NQ/qWXUaR2vyKPQ1pxNvBmw9LtbVMYb6 aQIgD9Y3DWtGgc1Af+j3u2LJuUzzyNs5qwnOmgd6kRJa19W+1TVS358kjQylqactevwsoLLQztd10 OLOkF63MdnuWPeea0A1M0uIwd7x6kqsgrN3pM+kHKmfc4JLADRuj6LOg36ljo1R0tW4ifUeti/tX+ amXMQPX+65O8spmleGDA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oGeVz-00CWtP-E4; Wed, 27 Jul 2022 10:43:44 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oGeVv-00CWqS-5h for linux-arm-kernel@lists.infradead.org; Wed, 27 Jul 2022 10:43:40 +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 8ADA215BF; Wed, 27 Jul 2022 03:43:36 -0700 (PDT) Received: from monolith.localdoman (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EE9C93F70D; Wed, 27 Jul 2022 03:43:34 -0700 (PDT) Date: Wed, 27 Jul 2022 11:44:15 +0100 From: Alexandru Elisei To: Marc Zyngier Cc: Oliver Upton , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: KVM/arm64: SPE: Translate VA to IPA on a stage 2 fault instead of pinning VM memory Message-ID: References: <20220419141012.GB6143@willie-the-truck> <04dea801e298374fb783bf0760b15241@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <04dea801e298374fb783bf0760b15241@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220727_034339_285541_2F1E50D6 X-CRM114-Status: GOOD ( 25.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Wed, Jul 27, 2022 at 11:29:03AM +0100, Marc Zyngier wrote: > On 2022-07-27 11:19, Alexandru Elisei wrote: > > Hi Oliver, > > > > Thank you for the help, replies below. > > > > On Tue, Jul 26, 2022 at 10:51:21AM -0700, Oliver Upton wrote: > > > Hi Alex, > > > > > > On Mon, Jul 25, 2022 at 11:06:24AM +0100, Alexandru Elisei wrote: > > > > > > [...] > > > > > > > > A funkier approach might be to defer pinning of the buffer until the SPE is > > > > > enabled and avoid pinning all of VM memory that way, although I can't > > > > > immediately tell how flexible the architecture is in allowing you to cache > > > > > the base/limit values. > > > > > > > > I was investigating this approach, and Mark raised a concern that I think > > > > might be a showstopper. > > > > > > > > Let's consider this scenario: > > > > > > > > Initial conditions: guest at EL1, profiling disabled (PMBLIMITR_EL1.E = 0, > > > > PMBSR_EL1.S = 0, PMSCR_EL1.{E0SPE,E1SPE} = {0,0}). > > > > > > > > 1. Guest programs the buffer and enables it (PMBLIMITR_EL1.E = 1). > > > > 2. Guest programs SPE to enable profiling at **EL0** > > > > (PMSCR_EL1.{E0SPE,E1SPE} = {1,0}). > > > > 3. Guest changes the translation table entries for the buffer. The > > > > architecture allows this. > > > > 4. Guest does an ERET to EL0, thus enabling profiling. > > > > > > > > Since KVM cannot trap the ERET to EL0, it will be impossible for KVM to pin > > > > the buffer at stage 2 when profiling gets enabled at EL0. > > > > > > Not saying we necessarily should, but this is possible with FGT no? > > > > It doesn't look to me like FEAT_FGT offers any knobs to trap ERET from > > EL1. > > See HFGITR.ERET. Ah, so that's the register, thanks! I stil am not sure that having FEAT_SPE, an Armv8.3 extension, depend on FEAT_FGT, an Armv8.6 extension, is the best idea. Do you know of any machines that have FEAT_SPE and FEAT_FGT? On the plus side, KVM could enable the trap only in the case above, and disable it after the ERET is trapped, so it should be relatively cheap to use. Thanks, Alex > > Thanks, > > M. > -- > Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel