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 E774CC04A68 for ; Wed, 27 Jul 2022 15:16:51 +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=2SLgU3wHBuoH2mdO6KX8ZycDevQ5IKgvP5sJWlerktU=; b=CpAj/g9l4L1qlv flLCVVjEe+a+IsomqLcAcTIhqDQCj6iGeAEoMTAxGb0Ivyl7/YhJt0FftT/KMt1wo3KhDCjj/kHtF +sE4vlPmEa8RET/oEA3RalWZhnEmkMn+aqhOFMO3o81RA/rYQCfssi7LhdjhQ+3TSnEJ1tbLzxGFd YfrpIUEA5uIpBK9uOBqXwKdxmJbYP3MGOV5JGwDwJOsW5qM9+gk0+7l3hyPA9CbdzxJ4xCg2WNPnO NucnMJCylFKLQgbzHuXa3IPmZnCkVP0YpV7LuvSF5vbdAg3F3uLcBT4bzlOXt/RzkTWsg7YQdgKdT 4z1IZIGhiYScKTT8u7HQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oGilH-00Ew9Z-A7; Wed, 27 Jul 2022 15:15:47 +0000 Received: from out2.migadu.com ([2001:41d0:2:aacc::]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oGil4-00Ew0G-7p for linux-arm-kernel@lists.infradead.org; Wed, 27 Jul 2022 15:15:36 +0000 Date: Wed, 27 Jul 2022 15:15:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1658934927; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eTFBBzy3zFLMXchXyWWwnL7LL8lRFXc0KZ1uZEaoQdc=; b=tGUEzhzFMPq6h1cj66qOQTSeQe+u8PgEf87LSBG21IVs74u2z6PFZtabf04Ikjc8fCfLDq S+9pYH8afSrzBFnjznkEjG2DBN8PKKaOJC6ZnMbTGdDe1Kyr3RcDNOgV6cOptGxFG3hI0m cUvnHOSNc9tFHlUi+j/qX5/3CUj36EM= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Alexandru Elisei Cc: Marc Zyngier , 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> <2d1f87576ce17b8c72bfac522e2aa101@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220727_081535_046320_CEBE947B X-CRM114-Status: GOOD ( 36.89 ) 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 12:57:16PM +0100, Alexandru Elisei wrote: > Hi, > > On Wed, Jul 27, 2022 at 12:08:11PM +0100, Marc Zyngier wrote: > > On 2022-07-27 11:44, Alexandru Elisei wrote: > > > 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? > > > > None. Both are pretty niche, and the combination is nowhere > > to be seen at the moment. > > That was also my impression. > > > > > > 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. > > > > This feels pretty horrible. Nothing says *when* will EL1 > > alter the PTs. It could take tons of EL1->EL1 exceptions > > before returning to EL0. And the change could happen after > > an EL1->EL0->EL1 transition. At which point do you stop? > > ERET trapping is enabled When PMBLIMITR_EL1.E = 1, PMSCR_EL1.{E0SPE,E1SPE} > = {1,0}. The first guest ERET from EL1 to EL0 enables profiling, at which > point the buffer is pinned and ERET trapping is disabled. > > Guest messing with the translation tables while profiling is enabled is the > guest's problem because that's not permitted by the architecture. Any stage > 2 dabt taken when the buffer is pinned would be injected back into the > guest as an SPE external abort (or something equivalent). Stage 1 dabts are > entirely the guest's problem to solve and would be injected back regardless > of the status of the buffer. > > Yes, I agree, there could be a lot of ERETs from EL1 to EL1 before the ERET > to EL0; those ERETs would be uselessly trapped. > > The above is a moot point anyway, because I believe we both agree that > having SPE emulation depend on FEAT_FGT is best to be avoided. LOL, I probably shouldn't have even mentioned it :) Completely agree with you both, trapping ERET is bordering on mad. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel