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 3DE77C4332F for ; Thu, 15 Dec 2022 09:36:52 +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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=pmWC/TFy3Ayv3EpLakInM4Fp88BsCLEAeUFWIl3x+/4=; b=2CRTp6/hljAs8Z uEr6NLGZtVtaSDBr5IM4LnghZpJVC/pVOHkRl17Uja1OYc8ikTnAbipnHDptn5p7GBc/xfTQx8x+y phP6EqiL5LLBrrBA3mTzgB9B3GQ1UjoEaFtnK7Kzeq+y5AQlReNXdaABzTouHO4YwBgoWi8yFZues gj2BRg8vPnmbEruuW3DGh3ko8oyW8sgxrsbVHsjSZnb/S7VTJrsE5DsFfByl7y/GIDNy2QzGJNXeS Jy+JBVVj9DZI2siwzcmoC6dUHqD7CF+3VNIdYk0+IiQa6AMk1PltqEZCv6If3484Ck/XYSD0G4BaP wskZeoYMCJdvCCWUWROQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p5keg-008M3Y-6P; Thu, 15 Dec 2022 09:35:54 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p5kec-008LzB-CM for linux-arm-kernel@lists.infradead.org; Thu, 15 Dec 2022 09:35:52 +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 ams.source.kernel.org (Postfix) with ESMTPS id 940F6B8169B; Thu, 15 Dec 2022 09:35:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37E7CC433EF; Thu, 15 Dec 2022 09:35:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1671096947; bh=rLFesypilBrGnzbTCpHcHD3EFyvffkyej22PhZqXN2g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=iEt1o047x3244dDOObFe5Q9vnB/j2CjEWFFT9jp1G2G7MGAqLlQnbHBVfsVwRrlqI Mof2r+180bPGwjZwvaGQlKcTcwoSbLNaO6rC69UjNCzD7QnrDqhXOi7miqnanfxX98 reTiiT/9aqjPBGLGysryw4rdzH3zBxZUyOXiYN2A/zxf0BwdxVrzUffemLdu2wrxe3 3k7u+yDUv7SjspMaST26q/MgRRmW5IYEyuLYrOvktgFIVTiGIUGlmxsizriR/PDj1e fIODM7uky1QuQfgnG85BfQZNXf25pPO09H0mQNf0DKVfjXhZiV8BqK2X6DKpophDls 9wNh2l2MeYBsQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1p5keW-00Co8M-OZ; Thu, 15 Dec 2022 09:35:44 +0000 Date: Thu, 15 Dec 2022 09:35:44 +0000 Message-ID: <86zgbpovpr.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: Ryan Roberts , Catalin Marinas , Will Deacon , Ard Biesheuvel , Suzuki K Poulose , Anshuman Khandual , James Morse , Alexandru Elisei , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu Subject: Re: [PATCH v1 00/12] KVM: arm64: Support FEAT_LPA2 at hyp s1 and vm s2 In-Reply-To: References: <20221206135930.3277585-1-ryan.roberts@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oliver.upton@linux.dev, ryan.roberts@arm.com, catalin.marinas@arm.com, will@kernel.org, ardb@kernel.org, suzuki.poulose@arm.com, anshuman.khandual@arm.com, james.morse@arm.com, alexandru.elisei@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, 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-20221215_013550_737033_0E5B792C X-CRM114-Status: GOOD ( 35.34 ) 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 Thu, 15 Dec 2022 00:52:28 +0000, Oliver Upton wrote: > > On Tue, Dec 06, 2022 at 01:59:18PM +0000, Ryan Roberts wrote: > > (appologies, I'm resending this series as I managed to send the cover letter to > > all but the following patches only to myself on first attempt). > > > > This is my first upstream feature submission so please go easy ;-) > > Welcome :) > > > Support 52-bit Output Addresses: FEAT_LPA2 changes the format of > > the PTEs. The HW advertises support for LPA2 independently for > > stage 1 and stage 2, and therefore its possible to have it for one > > and not the other. I've assumed that there is a valid case for > > this if stage 1 is not supported but stage 2 is, KVM could still > > then use LPA2 at stage 2 to create a 52 bit IPA space (which could > > then be consumed by a 64KB page guest kernel with the help of > > FEAT_LPA). Because of this independence and the fact that the kvm > > pgtable library is used for both stage 1 and stage 2 tables, this > > means the library now has to remember the in-use format on a > > per-page-table basis. To do this, I had to rework some functions > > to take a `struct kvm_pgtable *` parameter, and as a result, there > > is a noisy patch to add this parameter. > > Mismatch between the translation stages is an interesting problem... > > Given that userspace is responsible for setting up the IPA space, I > can't really think of a strong use case for 52 bit IPAs with a 48 bit > VA. Sure, the VMM could construct a sparse IPA space or remap the same > HVA at multiple IPAs to artificially saturate the address space, but > neither seems terribly compelling. > > Nonetheless, AFAICT we already allow this sort of mismatch on LPA && > !LVA systems. A 48 bit userspace could construct a 52 bit IPA space for > its guest. > > Marc, is there any real reason for this or is it just a byproduct of how > LPA support was added to KVM? My recollection is hazy, but LPA came first, and LVA only landed much later (because the two features were made independent in the architecture, something that was later abandoned for LPA2, which implies large VAs as well). So yes, the VMM can place memory wherever it wants in the 52bit IPA space, even if its own VA space is limited to 48 bits. And it doesn't have to be memory, by the way. You could place all the emulated MMIO above the 48bit limit, for example, and that doesn't require any trick other than the HW supporting 52bit PAs, and VTCR_EL2 being correctly configured. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel