From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3EC8221196210 for ; Tue, 27 Nov 2018 04:11:10 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A9D8A307DAB3; Tue, 27 Nov 2018 12:11:09 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-96.rdu2.redhat.com [10.10.120.96]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3FF915DD63; Tue, 27 Nov 2018 12:11:03 +0000 (UTC) To: Ard Biesheuvel , edk2-devel@lists.01.org Cc: Leif Lindholm , Eric Auger , Andrew Jones , Philippe Mathieu-Daude , Julien Grall References: <20181126223801.17121-1-ard.biesheuvel@linaro.org> From: Laszlo Ersek Message-ID: <006d48a9-8102-3e57-1f3b-20e8082ae612@redhat.com> Date: Tue, 27 Nov 2018 13:11:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181126223801.17121-1-ard.biesheuvel@linaro.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Tue, 27 Nov 2018 12:11:09 +0000 (UTC) Subject: Re: [PATCH v2 00/13] ArmPkg, ArmVirtPkg: lift 40-bit IPA space limit X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 12:11:11 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 11/26/18 23:37, Ard Biesheuvel wrote: > The ArmVirtQemu targets currently limit the size of the IPA space to > 40 bits because that is all what KVM supports. However, this is about > to change, and so we need to update the code if we want to ensure that > our UEFI firmware builds can keep running on systems that set values > other than 40 (which could be > 40 or < 40) > > So refactor the way we deal with this limit, both for bare metal and for > virtual targets, so that > a) the range of the GCD memory map is based directly on the CPU's PA range > b) the range of the 1:1 mapping in the page tables is based on the CPU's PA > range (unless it exceeds what the architecture permits for 4k pages) > c) PcdPrePiCpuMemorySize is no longer needed, and can be removed. > > Patch #1 introduces ARM_MMU_IDMAP_RANGE and ArmGetPhysicalAddressBits () > in ArmLib. OK, so the crucial piece of info I missed under v1 was that given the fixed 4KB page size under UEFI, we might not be able to identity map all the memory that the CPU would otherwise be capable of addressing (assuming the OS set up a larger page size). However... that seems to leave us with a conundrum. (I'm 100% sure it is nothing new to you, but it is new to me.) If we size the GCD memory space map exactly to what we can identity map under UEFI, then the UEFI memmap will not advertize the rest of the RAM to the OS, and the memory will be unusable. On the other hand, if we size the GCD to the exact RAM size (part of which could be out of reach for the CPU *under UEFI*, using 4KB pages), then the OS will be happy. But, what happens when gBS->AllocatePages() is served from such a high (>48bits) address range, and then the client module tries to access the (not mapped) chunk? Hm... Actually, once this becomes a practical problem, I think we can take care of it, in a platform PEIM. Namely, just pre-allocate the entire inaccessible / unmappable range (beyond 48-bits) as Boot Services Data type memory. That will keep the rest of the firmware out (no well-behaving module will read or write memory that it didn't allocate), and the OS will be happy to release and reuse that memory. Does this make sense? I'd like to be sure that I understand this right, before starting my v2 review. Thanks! Laszlo