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 0DBF32117FD5E for ; Tue, 27 Nov 2018 06:35:37 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 273DC3086260; Tue, 27 Nov 2018 14:35:37 +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 E873F608E0; Tue, 27 Nov 2018 14:35:34 +0000 (UTC) To: Ard Biesheuvel Cc: "edk2-devel@lists.01.org" , Leif Lindholm , Auger Eric , Andrew Jones , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , Julien Grall References: <20181126223801.17121-1-ard.biesheuvel@linaro.org> <006d48a9-8102-3e57-1f3b-20e8082ae612@redhat.com> From: Laszlo Ersek Message-ID: <1230a004-1c33-0912-cc04-87a1b5a31bb6@redhat.com> Date: Tue, 27 Nov 2018 15:35:33 +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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Tue, 27 Nov 2018 14:35:37 +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 14:35:38 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 11/27/18 13:13, Ard Biesheuvel wrote: > On Tue, 27 Nov 2018 at 13:11, Laszlo Ersek wrote: >> >> 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? >> > > That is an excellent question, given that IA32 and ARM are in exactly > the same boat with [L]PAE. And that's an excellent observation too; I should have noticed the parallel with at least IA32 myself! I remember the article where Brian explains why vendors ship IA32-only firmware on 64-bit capable Intel processors. Hm... It's here: https://software.intel.com/en-us/blogs/2015/07/22/why-cheap-systems-run-32-bit-uefi-on-x64-systems Obviously Linux people were never happy with that, so they worked around it, and the kernel switches to 64-bit mode itself, AFAIK... But what about the RAM that the 32-bit DXE phase (and firmware runtime) can't see, but the OS can? Maybe Linux can provide some pointers here (as you say). [...] Thank you! Laszlo