From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::144; helo=mail-it1-x144.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x144.google.com (mail-it1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 551A62118EF65 for ; Tue, 27 Nov 2018 13:18:28 -0800 (PST) Received: by mail-it1-x144.google.com with SMTP id m123-v6so890830ita.4 for ; Tue, 27 Nov 2018 13:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ec+liIivpfxz1qlkIRNqbVAZBxW+gxKS79c81YSMY00=; b=EIdkppGAsMfmmVntxXGOFIK9oRffsA9t4rLKAqZvO9eKKxhaojxnsa2gzQzwomThZA UdO1pllQJpNJn9+TTFv3PFv+ZzCCGxeYiAhuusPAOOGrDD75LUxa93W8SUxKuoGE6uwb GR2NVcO+/xmBj6IfGeOHVP8jQgWLsmVfJHL0E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ec+liIivpfxz1qlkIRNqbVAZBxW+gxKS79c81YSMY00=; b=kRrqTycQZ8RckuQd+v10lkg/dOdAHvd1XlWuF8ufJTYp+nByKdq1doEs7n9pjgYqY4 4ZHAkjORgAdO2EZkI9zIqGQAZ36FyPqrwb7AxxT5UpOwxhjUTg5MQiHAe7qaotUEJ1/r gmJKTOjUoK62CSK3Aws4E3AoqEebEbPTjhqIJUXLvx/fA1S5c/aSPh8pEVjb65HZMRs6 1XRAzeT9Uq1ZpoWQ2iVRYtU7UQoPL9sVi/wH830KKcilsVfN0ruOhD+Jo8eUd5RiHI2g T0MOpVmrWSWUliaym3RRkuWQyjnAWwXDjcdqHvLQMEVX5SMwN7xz/RozCSp6DVdDcX/3 yOmw== X-Gm-Message-State: AA+aEWac7Cf8a1/RVJ18yb3889iT3YLe4Sia8Gcy+uWtoHpELsBoSVad F9sNAgJ112z72MO4VNUOyNB3LlXPSiED+kT6W6XPtQ== X-Google-Smtp-Source: AFSGD/VgaBQeukvU+VLpawE2sfoZcusTGYLYBNTidhuEaEkJpSWXpH1C+CuQ/pLRw85WQk8pPcMKXxiMP4PO1t1GTDk= X-Received: by 2002:a05:660c:4b:: with SMTP id p11mr552876itk.71.1543353507555; Tue, 27 Nov 2018 13:18:27 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <48e12ce4-8f1d-f60e-19f2-0a4029d8632c@redhat.com> From: Ard Biesheuvel Date: Tue, 27 Nov 2018 22:18:16 +0100 Message-ID: To: Laszlo Ersek Cc: "edk2-devel@lists.01.org" , Andrew Jones , Auger Eric 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: Tue, 27 Nov 2018 21:18:28 -0000 Content-Type: text/plain; charset="UTF-8" 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 :-) Apologies, I managed to confuse myself a bit as well, so I understand this may be slightly difficult to follow. > 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.