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=-14.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 66A4AC433C1 for ; Tue, 30 Mar 2021 12:46:28 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 01DEA61957 for ; Tue, 30 Mar 2021 12:46:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 01DEA61957 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=desiato.20200630; 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=kSOzh0NuazUDEvB6aDikT9BX2rOVLF8k6lXFhjtSMXU=; b=nEwKSkLVGxQK6cKus24lG3iKw LeSHC4qSL7gTp1u9En1c4llYvNpWkOzKz2p2oXemmVsxa/70OaZ4h4ADgzsyhw+2A+eKBOfRqU5kB w/CHoLgohZCmNzZtunnuQ+3CcY5/lmw8FdSbvxQ+E2x3vSlNLb6qvoRYJjalyXuk4JM0vraxm73oK I6ooqIgnJ9QOAoGa+TVTDIrvcbP4hWw6h69lMdLEa2teeeM01yKUCX6ffeplgvWZcDmDtkezmMJCw DS+rOunV0Dh/tTQlKu5ToeFeACOAZzCt2L5+bTMFiouc5PNw9ACSd9dqwhRO649ln65JdzE8+8hts ZJs/qT8mg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lRDjg-003ioz-8I; Tue, 30 Mar 2021 12:44:44 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lRDjR-003inm-BG for linux-arm-kernel@lists.infradead.org; Tue, 30 Mar 2021 12:44:33 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1D5A661957; Tue, 30 Mar 2021 12:44:28 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lRDjO-004g2i-7W; Tue, 30 Mar 2021 13:44:26 +0100 Date: Tue, 30 Mar 2021 13:44:25 +0100 Message-ID: <87lfa4rety.wl-maz@kernel.org> From: Marc Zyngier To: Ard Biesheuvel Cc: linux-arm-kernel@lists.infradead.org, will@kernel.org, kernel-team@android.com, anshuman.khandual@arm.com, steve.capper@arm.com, catalin.marinas@arm.com, kvmarm@lists.cs.columbia.edu, qperret@google.com Subject: Re: [PATCH] arm64: kvm: handle 52-bit VA regions correctly under nVHE In-Reply-To: <20210330112126.463336-1-ardb@kernel.org> References: <20210330112126.463336-1-ardb@kernel.org> 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 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: ardb@kernel.org, linux-arm-kernel@lists.infradead.org, will@kernel.org, kernel-team@android.com, anshuman.khandual@arm.com, steve.capper@arm.com, catalin.marinas@arm.com, kvmarm@lists.cs.columbia.edu, qperret@google.com 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-20210330_134431_987190_11979060 X-CRM114-Status: GOOD ( 40.02 ) 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 Tue, 30 Mar 2021 12:21:26 +0100, Ard Biesheuvel wrote: > > Commit f4693c2716b35d08 ("arm64: mm: extend linear region for 52-bit VA > configurations") introduced a new layout for the 52-bit VA space, in > order to maximize the space available to the linear region. After this > change, the kernel VA space is no longer split 1:1 down the middle, and > as it turns out, this violates an assumption in the KVM init code when > it chooses the layout for the nVHE EL2 mapping. > > Given that EFI does not support 52-bit VA addressing (as it only > supports 4k pages), and that in general, loaders cannot assume that the > kernel being loaded supports 52-bit VA/PA addressing in the first place, > we can safely assume that the kernel, and therefore the .idmap section, > will be 48-bit addressable on 52-bit VA capable systems. > > So in this case, organize the nVHE EL2 address space as a 2^48 byte > window starting at address 0x0, containing the ID map and the > hypervisor's private mappings, followed by a contiguous 2^52 - 2^48 byte > linear region. (Note that EL1's linear region is 2^52 - 2^47 bytes in > size, so it is slightly larger, but this only matters on systems where > the DRAM footprint in the physical memory map exceeds 3968 TB) So if I have memory in the [2^52 - 2^48, 2^52 - 2^47] range, not necessarily because I have that much memory, but because my system has multiple memory banks, one of which lands on that spot, I cannot map such memory at EL2. We'll explode at run time. Can we keep the private mapping to 47 bits and restore the missing chunk to the linear mapping? Of course, it means that the linear map is now potential no linear anymore, so we'd have to garantee that the kernel lines in the first 2^47 bits instead. Crap. > > Fixes: f4693c2716b35d08 ("arm64: mm: extend linear region for 52-bit VA configurations") > Signed-off-by: Ard Biesheuvel > --- > Documentation/arm64/booting.rst | 6 +++--- > arch/arm64/kvm/va_layout.c | 18 ++++++++++++++---- > 2 files changed, 17 insertions(+), 7 deletions(-) > > diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst > index 7552dbc1cc54..418ec9b63d2c 100644 > --- a/Documentation/arm64/booting.rst > +++ b/Documentation/arm64/booting.rst > @@ -121,8 +121,8 @@ Header notes: > to the base of DRAM, since memory below it is not > accessible via the linear mapping > 1 > - 2MB aligned base may be anywhere in physical > - memory > + 2MB aligned base may be anywhere in the 48-bit > + addressable physical memory region > Bits 4-63 Reserved. > ============= =============================================================== > > @@ -132,7 +132,7 @@ Header notes: > depending on selected features, and is effectively unbound. > > The Image must be placed text_offset bytes from a 2MB aligned base > -address anywhere in usable system RAM and called there. The region > +address in 48-bit addressable system RAM and called there. The region > between the 2 MB aligned base address and the start of the image has no > special significance to the kernel, and may be used for other purposes. > At least image_size bytes from the start of the image must be free for > diff --git a/arch/arm64/kvm/va_layout.c b/arch/arm64/kvm/va_layout.c > index 978301392d67..e9ab449de197 100644 > --- a/arch/arm64/kvm/va_layout.c > +++ b/arch/arm64/kvm/va_layout.c > @@ -62,9 +62,19 @@ __init void kvm_compute_layout(void) > phys_addr_t idmap_addr = __pa_symbol(__hyp_idmap_text_start); > u64 hyp_va_msb; > > - /* Where is my RAM region? */ > - hyp_va_msb = idmap_addr & BIT(vabits_actual - 1); > - hyp_va_msb ^= BIT(vabits_actual - 1); > + /* > + * On LVA capable hardware, the kernel is guaranteed to reside > + * in the 48-bit addressable part of physical memory, and so > + * the idmap will be located there as well. Put the EL2 linear > + * region right after it, where it can grow upward to fill the > + * entire 52-bit VA region. > + */ > + if (vabits_actual > VA_BITS_MIN) { > + hyp_va_msb = BIT(VA_BITS_MIN); > + } else { > + hyp_va_msb = idmap_addr & BIT(vabits_actual - 1); > + hyp_va_msb ^= BIT(vabits_actual - 1); > + } > > tag_lsb = fls64((u64)phys_to_virt(memblock_start_of_DRAM()) ^ > (u64)(high_memory - 1)); > @@ -72,7 +82,7 @@ __init void kvm_compute_layout(void) > va_mask = GENMASK_ULL(tag_lsb - 1, 0); > tag_val = hyp_va_msb; > > - if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && tag_lsb != (vabits_actual - 1)) { > + if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && tag_lsb < (vabits_actual - 1)) { > /* We have some free bits to insert a random tag. */ > tag_val |= get_random_long() & GENMASK_ULL(vabits_actual - 2, tag_lsb); > } It seems __create_hyp_private mapping() still refers to (VA_BITS - 1) to choose where to allocate the IO mappings, and __pkvm_create_private_mapping() relies on similar things based on what hyp_create_idmap(). 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