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 E95A9C433DB for ; Tue, 30 Mar 2021 13:17:21 +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 7D923600CD for ; Tue, 30 Mar 2021 13:17:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D923600CD 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:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=l4ghwPPR7DApDPu/uY+n3Mnv0uJUqNkEBG2t18vTX5U=; b=Jtt7FGPCfyHKKhtKaM3rJvpBS G+i9AQvfnXhxe5fPLrix6Y1aNyVBPE0VKk2q5qnwf8jHcdgyu2/u0TabRkx5+A2+SxYR1zgKdFCWQ X1Zmd48ttJOXRTUqMAMMcj+mhhq9qS17a6dgCaL7lmBX6VTemtoW1HZCDiQZs0jXD69XToimmCUH1 vSD/EbntTVZ4NcBnfXJDGOqPrhUAJSZhtoWHxhD9TAnWngSRuuwh8BdOW/OdZvdZuFA7c1LwyDSBg wsb/TUjFt9sB8XmG+KAy32ArJQBtzLuZZ4CijqTsLzKMW8vMBXk3v0ELhHakq1beM2Y7m2+is//XG qrerTLWVw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lREDb-003o9D-Oy; Tue, 30 Mar 2021 13:15:39 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lREDV-003o89-DO for linux-arm-kernel@lists.infradead.org; Tue, 30 Mar 2021 13:15:36 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id EF517619BB for ; Tue, 30 Mar 2021 13:15:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617110132; bh=jYNEUTXvynh04DROg9mQqri4jkuuAHDVFQ/ifDTw1aU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=fvE+K9XCmTESjp8RsSNZLoaayk8eWHPMJVEDwwpCiHWnhYat8b+RnIiWwgYj8+Z3j bYwLzdXJsxPgQyPRmjKLK112VFZJegYkOW5C0s4uZspBPfE3TVe9QaLK+p6Ev/OpIs +HwL+dPO4lYZk5tUsYSDgVEcgnx8hKelzorpjo89v0eQKkBZNqAbXmhigN29StkxFO QUa36HJf/I+q4blQGzEPoC0Kul4Qj6skaKfD+f29HN2Iw5PANerZbVzL44SsWCbNuw zAVtApPJCzmbTVtGsXqHDdbGFtVsI+1gIjLDSUkJuHt9PxyflaF3XdshYwwq6POTiy P/P8aM7UjLO/w== Received: by mail-ot1-f45.google.com with SMTP id g8-20020a9d6c480000b02901b65ca2432cso15529391otq.3 for ; Tue, 30 Mar 2021 06:15:31 -0700 (PDT) X-Gm-Message-State: AOAM530iz/TzYiLjNCrNRtXPGlr4dQ4DDIrngnKs3avTP+LPwmqoqans pyxjacczmfOgaHShGlt0gXSMaBt9cA6cz1rvqIU= X-Google-Smtp-Source: ABdhPJxe75+FB/j3ON1xpr+EmfIcZ+jOzQfmkF7Wp0iGHNsGHCCtBZewDZ/ID2liijKOyO7fB8pjFyx5Y2cVl2dgN2c= X-Received: by 2002:a9d:7ccf:: with SMTP id r15mr16161921otn.108.1617110131343; Tue, 30 Mar 2021 06:15:31 -0700 (PDT) MIME-Version: 1.0 References: <20210330112126.463336-1-ardb@kernel.org> <87lfa4rety.wl-maz@kernel.org> <87k0pordvw.wl-maz@kernel.org> In-Reply-To: <87k0pordvw.wl-maz@kernel.org> From: Ard Biesheuvel Date: Tue, 30 Mar 2021 15:15:19 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] arm64: kvm: handle 52-bit VA regions correctly under nVHE To: Marc Zyngier Cc: Linux ARM , Will Deacon , Android Kernel Team , Anshuman Khandual , Steve Capper , Catalin Marinas , kvmarm , Quentin Perret X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210330_141534_053770_412ED4A8 X-CRM114-Status: GOOD ( 32.62 ) 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 at 15:04, Marc Zyngier wrote: > > 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. > Yeah, especially given the fact that LVA systems will be VHE capable and may therefore not care in the first place. On systems that have memory that high, EFI is likely to load the kernel there, as it usually allocates from the top down, and it tries to avoid having to move it around unless asked to (via KASLR), in which case it will currently randomize over the entire available memory space. So it is going to add a special case for a corner^2 case, i.e., nVHE on 52-bit/64k pages with more than 3968 TB distance between the start and end of DRAM. Ugh. It seems to me that the only way to solve this is to permit the idmap and the hyp linear region to overlap, and use the 2^47 byte window at the top of the address space for the hyp private mappings instead of the one at the bottom. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel