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=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 9D481C433C1 for ; Tue, 30 Mar 2021 13:05:01 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id EBB6A619C7 for ; Tue, 30 Mar 2021 13:05:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EBB6A619C7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6B3D54B30F; Tue, 30 Mar 2021 09:05:00 -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 cRW9ofIrgZcI; Tue, 30 Mar 2021 09:04:59 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4A5344B306; Tue, 30 Mar 2021 09:04:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4FDA84B2FA for ; Tue, 30 Mar 2021 09:04:58 -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 EfOe5iUd0W58 for ; Tue, 30 Mar 2021 09:04:57 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 10A3F4B1CF for ; Tue, 30 Mar 2021 09:04:57 -0400 (EDT) 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 51B8F619C6; Tue, 30 Mar 2021 13:04:54 +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 1lRE3A-004gLV-5n; Tue, 30 Mar 2021 14:04:52 +0100 Date: Tue, 30 Mar 2021 14:04:51 +0100 Message-ID: <87k0pordvw.wl-maz@kernel.org> From: Marc Zyngier To: Ard Biesheuvel Subject: Re: [PATCH] arm64: kvm: handle 52-bit VA regions correctly under nVHE In-Reply-To: References: <20210330112126.463336-1-ardb@kernel.org> <87lfa4rety.wl-maz@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 Cc: Will Deacon , Anshuman Khandual , Catalin Marinas , Android Kernel Team , kvmarm , Linux ARM 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Tue, 30 Mar 2021 13:49:18 +0100, Ard Biesheuvel wrote: > > On Tue, 30 Mar 2021 at 14:44, Marc Zyngier wrote: > > > > 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. > > > > Yeah. The linear region needs to be contiguous. Alternatively, we > could restrict the upper address limit for loading the kernel to 47 > bits. Is that something we can do retroactively? We could mandate it for LVA systems only, but that's a bit odd. [...] > > 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(). > > > > That was probably broken already then, given that it should refer to > vabits_actual. I'll address that in a separate patch. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ 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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 5C6A9C433DB for ; Tue, 30 Mar 2021 13:06:39 +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 EC8EE619C7 for ; Tue, 30 Mar 2021 13:06:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EC8EE619C7 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=EzKaWPW/J7CFaj5jE67AliSQSxIrd+4f48Mr+XGz8X8=; b=g6nkj4zDdggeSllGby1crQwQm NhUh3nOCWzN0PWRwvQT/ohdlguVLUb3P3ONtbwR67VM8uJsd4PiKhl1DcPktPgSTM7CDEZ/Cwbp4Y 82xAipJuF87MlOYypMyELWe7Av9xGpPf+g6AgkKHYIMAXRT/2VUFcUI1yjP0E1b07cJJP5xe7SfWG n0nsquaHK4VGMsfT/IsNkNvDoATvVGhsMZ8hA/UU7PSoB8/8yR7YOkJOB8z7PYruXVbSGtHJfcg9Y AOhCO1EKJDK6Rz6qIgs+skx3cL6V2q0aRdgLKzszfnO0hka86msG7xP5w+ovSf0sE8Bn17hpcnPl/ /MnVGwCLw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lRE3K-003lv9-On; Tue, 30 Mar 2021 13:05:02 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lRE3D-003ltz-OA for linux-arm-kernel@lists.infradead.org; Tue, 30 Mar 2021 13:04:57 +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 51B8F619C6; Tue, 30 Mar 2021 13:04:54 +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 1lRE3A-004gLV-5n; Tue, 30 Mar 2021 14:04:52 +0100 Date: Tue, 30 Mar 2021 14:04:51 +0100 Message-ID: <87k0pordvw.wl-maz@kernel.org> From: Marc Zyngier To: Ard Biesheuvel Cc: Linux ARM , Will Deacon , Android Kernel Team , Anshuman Khandual , Steve Capper , Catalin Marinas , kvmarm , Quentin Perret Subject: Re: [PATCH] arm64: kvm: handle 52-bit VA regions correctly under nVHE In-Reply-To: References: <20210330112126.463336-1-ardb@kernel.org> <87lfa4rety.wl-maz@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_140456_128875_8B9E9423 X-CRM114-Status: GOOD ( 34.92 ) 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 13:49:18 +0100, Ard Biesheuvel wrote: > > On Tue, 30 Mar 2021 at 14:44, Marc Zyngier wrote: > > > > 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. > > > > Yeah. The linear region needs to be contiguous. Alternatively, we > could restrict the upper address limit for loading the kernel to 47 > bits. Is that something we can do retroactively? We could mandate it for LVA systems only, but that's a bit odd. [...] > > 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(). > > > > That was probably broken already then, given that it should refer to > vabits_actual. I'll address that in a separate patch. 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