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 99C902116821B for ; Wed, 28 Nov 2018 04:12:33 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 30EDF7653B; Wed, 28 Nov 2018 12:12:33 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-170.rdu2.redhat.com [10.10.120.170]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1595F101962B; Wed, 28 Nov 2018 12:12:31 +0000 (UTC) To: Ard Biesheuvel Cc: "edk2-devel@lists.01.org" , Andrew Jones References: <20181127145418.11992-1-ard.biesheuvel@linaro.org> <20181127145418.11992-3-ard.biesheuvel@linaro.org> <761d65bc-2e63-b061-258a-d7f6915371cf@redhat.com> <48e12ce4-8f1d-f60e-19f2-0a4029d8632c@redhat.com> From: Laszlo Ersek Message-ID: <737e5363-9c9d-b326-8930-7976a1dfba89@redhat.com> Date: Wed, 28 Nov 2018 13:12:30 +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.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 28 Nov 2018 12:12:33 +0000 (UTC) Subject: Re: [PATCH v2 2/2] ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range 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: Wed, 28 Nov 2018 12:12:33 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 11/27/18 22:18, Ard Biesheuvel wrote: > On Tue, 27 Nov 2018 at 21:25, Laszlo Ersek wrote: >> >> On 11/27/18 18:52, Ard Biesheuvel wrote: >>> On Tue, 27 Nov 2018 at 18:26, Laszlo Ersek wrote: >>>> >>>> On 11/27/18 15:54, Ard Biesheuvel wrote: >>>>> Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the >>>>> entire virtual address space is mapped with EFI_MEMORY_UC attributes, >>>>> regardless of whether any devices actually reside there. >>>>> >>>>> Now that we are relaxing the address space limit to more than 40 bits, >>>>> mapping all that address space actually takes up more space in page >>>>> tables than we have so far made available as temporary RAM. So let's >>>>> get rid of the mapping rather than increasing the available RAM, given >>>>> that the mapping is not particularly useful anyway. >>>>> >>>>> Contributed-under: TianoCore Contribution Agreement 1.1 >>>>> Signed-off-by: Ard Biesheuvel >>>>> --- >>>>> ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c | 17 +++++------------ >>>>> 1 file changed, 5 insertions(+), 12 deletions(-) >>>>> >>>>> diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c >>>>> index 815ca145b644..70863abb2e7b 100644 >>>>> --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c >>>>> +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c >>>>> @@ -73,21 +73,14 @@ ArmVirtGetMemoryMap ( >>>>> VirtualMemoryTable[1].Length = VirtualMemoryTable[0].PhysicalBase; >>>>> VirtualMemoryTable[1].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE; >>>>> >>>>> - // Peripheral space after DRAM >>>>> - VirtualMemoryTable[2].PhysicalBase = VirtualMemoryTable[0].Length + VirtualMemoryTable[1].Length; >>>>> - VirtualMemoryTable[2].VirtualBase = VirtualMemoryTable[2].PhysicalBase; >>>>> - VirtualMemoryTable[2].Length = TopOfAddressSpace - >>>>> - VirtualMemoryTable[2].PhysicalBase; >>>>> - VirtualMemoryTable[2].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE; >>>>> - >>>>> // Remap the FD region as normal executable memory >>>>> - VirtualMemoryTable[3].PhysicalBase = PcdGet64 (PcdFdBaseAddress); >>>>> - VirtualMemoryTable[3].VirtualBase = VirtualMemoryTable[3].PhysicalBase; >>>>> - VirtualMemoryTable[3].Length = FixedPcdGet32 (PcdFdSize); >>>>> - VirtualMemoryTable[3].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK; >>>>> + VirtualMemoryTable[2].PhysicalBase = PcdGet64 (PcdFdBaseAddress); >>>>> + VirtualMemoryTable[2].VirtualBase = VirtualMemoryTable[2].PhysicalBase; >>>>> + VirtualMemoryTable[2].Length = FixedPcdGet32 (PcdFdSize); >>>>> + VirtualMemoryTable[2].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK; >>>>> >>>>> // End of Table >>>>> - ZeroMem (&VirtualMemoryTable[4], sizeof (ARM_MEMORY_REGION_DESCRIPTOR)); >>>>> + ZeroMem (&VirtualMemoryTable[3], sizeof (ARM_MEMORY_REGION_DESCRIPTOR)); >>>>> >>>>> *VirtualMemoryMap = VirtualMemoryTable; >>>>> } >>>>> >>>> >>>> (1) This supplants your other series "[PATCH v2 00/13] ArmPkg, ArmVirtPkg: lift 40-bit IPA space limit" minimally due to a contextual conflict; is that right? >>>> >>> >>> Not quite. It complements it, in the sense that is should fix the >>> issue reported by Eric when mapping the entire address 48-bit address >>> space. >> >> Oh, you meant this one *on top* of that? In particular, on top of: >> >> [edk2] [PATCH v2 11/13] ArmVirtPkg/QemuVirtMemInfoLib: ignore >> PcdPrePiCpuMemorySize >> >> That wasn't clear to me, sorry. >> > > No, the other way around actually :-) How so? Patch v2 11/13 removes: > - VirtualMemoryTable[2].Length = TopOfMemory - and adds: > + VirtualMemoryTable[2].Length = TopOfAddressSpace - and in the current patch, you remove > - VirtualMemoryTable[2].Length = TopOfAddressSpace - So the current patch wouldn't apply before v2 11/13. Anyway, this is not so important :) > Apologies, I managed to confuse myself a bit as well, so I understand > this may be slightly difficult to follow. Yeah :) >> If this one comes on top of the v2 13-part series, do you ultimately >> need v2 11/13 as a separate patch -- in that form anyway? It seems that >> you could squash this patch into v2 11/13, and eliminate the dependency >> on PcdPrePiCpuMemorySize *by* killing the entry that maps the Peripheral >> space after DRAM. >> > > Indeed. So after applying these two patches, I will need to respin > that series once more, and now that I think of it, it might make sense > to simplify those changes signficantly, given that only the Xen code > needs to access the CPU's capability registers in the platform MMU > setup code. Thank you for explaining. I'll wait for the one and only v3 then. Thanks! Laszlo