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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id C51BEC19F29 for ; Wed, 27 Jul 2022 11:08:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 499934C469; Wed, 27 Jul 2022 07:08:18 -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=@kernel.org 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 JKFdH3X3W3wV; Wed, 27 Jul 2022 07:08:17 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 2956C4C450; Wed, 27 Jul 2022 07:08:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 729FD4C450 for ; Wed, 27 Jul 2022 07:08:16 -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 ppfAGeZ4eqxF for ; Wed, 27 Jul 2022 07:08:15 -0400 (EDT) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 4CD554C44F for ; Wed, 27 Jul 2022 07:08:15 -0400 (EDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 61B57618DE; Wed, 27 Jul 2022 11:08:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC34EC433D6; Wed, 27 Jul 2022 11:08:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658920093; bh=/jm3uoWxQ93coGguDiiUwoPxQE3ySaLLej5txbbt3lA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MciHgpjfW0CO6bUDMqxKlYFXhwrd/djSZf1DeInnqKp3jQ6R3fY+FGPOr5Re9I3Ik A4PpWkVyGsCzcImxpqGXYBsMm7OIG8A0gufWfuEJbjCcr4rpU5qzVF1cWHBGkaGxab sCykimfoGGoZC3kGPntUWlGSgOw338ySgSHd8qylz12J40iegFGxCiR1VIGt3ELHDj VKclQMb3Rl5y4i9S6WxLjiX6DAv0A/ydaT2N/Rp673SgUCvj0jBS4U8eKxHDzhAnYP FKN2jBZ6nUX1FvI9HjcqWWqhtd6rQPAFBvM2PA52u8szadGP5KKjFZj/HMxpH/L/i7 bDwsEzAMl0C6Q== Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oGetf-00ANZ2-HE; Wed, 27 Jul 2022 12:08:11 +0100 MIME-Version: 1.0 Date: Wed, 27 Jul 2022 12:08:11 +0100 From: Marc Zyngier To: Alexandru Elisei Subject: Re: KVM/arm64: SPE: Translate VA to IPA on a stage 2 fault instead of pinning VM memory In-Reply-To: References: <20220419141012.GB6143@willie-the-truck> <04dea801e298374fb783bf0760b15241@kernel.org> User-Agent: Roundcube Webmail/1.4.13 Message-ID: <2d1f87576ce17b8c72bfac522e2aa101@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: alexandru.elisei@arm.com, linux-arm-kernel@lists.infradead.org, will@kernel.org, kvmarm@lists.cs.columbia.edu X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list 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 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. > 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? If you want to rely on ERET for that, you need to trap ERET all the time, because all ERETs to EL0 will be suspect. And doing that to handle such a corner case feels pretty horrible. M. -- Jazz is not dead. It just smells funny... _______________________________________________ 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 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 9E595C04A68 for ; Wed, 27 Jul 2022 11:09:22 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:Cc:To:From :Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=vcBzJ+wcjeUvksmfWlDI7RUkj+3V1QoCEkgCmMJfjnE=; b=n3rONWk7DhUaEkuHLrGaSSK+wR v53pld0hje3mBFLWMdPQ2q1wFKYvCUFwbOAWzu103sboI45qVOlPFi8Z1HRsI8ZXYGTDC5D0Chri/ vi5ZelshXI/JPT4l8H/LKJVWcmETOy+a+y/2k4S3dkGBNdCFG5SGeZ7Mu/FwIr9snxYBGbd0tztbo rWzEmBWgtV7BbPZ7SfgR2zU3O/PUcAxVH86wLINDbaVJnxibrP9IhjYYT0X5J3xzjjSON96HdZ4Rr bsLLWi8K+JR/1TZZ0JkGTNgPqZBRNmntclrCrABN8yTsrOLTh72pwZUFlcpdkOUVlj+L8mTenviqc qvcCNwoQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oGetm-00ClPy-NR; Wed, 27 Jul 2022 11:08:18 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oGetj-00ClO5-14 for linux-arm-kernel@lists.infradead.org; Wed, 27 Jul 2022 11:08:16 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 61B57618DE; Wed, 27 Jul 2022 11:08:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC34EC433D6; Wed, 27 Jul 2022 11:08:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658920093; bh=/jm3uoWxQ93coGguDiiUwoPxQE3ySaLLej5txbbt3lA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MciHgpjfW0CO6bUDMqxKlYFXhwrd/djSZf1DeInnqKp3jQ6R3fY+FGPOr5Re9I3Ik A4PpWkVyGsCzcImxpqGXYBsMm7OIG8A0gufWfuEJbjCcr4rpU5qzVF1cWHBGkaGxab sCykimfoGGoZC3kGPntUWlGSgOw338ySgSHd8qylz12J40iegFGxCiR1VIGt3ELHDj VKclQMb3Rl5y4i9S6WxLjiX6DAv0A/ydaT2N/Rp673SgUCvj0jBS4U8eKxHDzhAnYP FKN2jBZ6nUX1FvI9HjcqWWqhtd6rQPAFBvM2PA52u8szadGP5KKjFZj/HMxpH/L/i7 bDwsEzAMl0C6Q== Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oGetf-00ANZ2-HE; Wed, 27 Jul 2022 12:08:11 +0100 MIME-Version: 1.0 Date: Wed, 27 Jul 2022 12:08:11 +0100 From: Marc Zyngier To: Alexandru Elisei Cc: linux-arm-kernel@lists.infradead.org, Will Deacon , kvmarm@lists.cs.columbia.edu Subject: Re: KVM/arm64: SPE: Translate VA to IPA on a stage 2 fault instead of pinning VM memory In-Reply-To: References: <20220419141012.GB6143@willie-the-truck> <04dea801e298374fb783bf0760b15241@kernel.org> User-Agent: Roundcube Webmail/1.4.13 Message-ID: <2d1f87576ce17b8c72bfac522e2aa101@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: alexandru.elisei@arm.com, linux-arm-kernel@lists.infradead.org, will@kernel.org, kvmarm@lists.cs.columbia.edu X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220727_040815_185894_F24304BB X-CRM114-Status: GOOD ( 30.09 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. > 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? If you want to rely on ERET for that, you need to trap ERET all the time, because all ERETs to EL0 will be suspect. And doing that to handle such a corner case feels pretty horrible. 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