From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey Hugo Subject: Re: [PATCH v3 06/10] arm64: efi: add EFI stub Date: Wed, 8 Feb 2017 10:22:36 -0700 Message-ID: <423ec003-225e-8a5f-c071-0fcbbec2679e@codeaurora.org> References: <1396637113-22790-1-git-send-email-leif.lindholm@linaro.org> <1396637113-22790-7-git-send-email-leif.lindholm@linaro.org> <73a460e5-98f5-86c2-142f-a9a084ee0203@codeaurora.org> <20170208170305.GI15459@leverpostej> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20170208170305.GI15459@leverpostej> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Mark Rutland , Timur Tabi Cc: linux-efi@vger.kernel.org, Ard Biesheuvel , Catalin Marinas , lkml , Leif Lindholm , Mark Salter , "linux-arm-kernel@lists.infradead.org" List-Id: linux-efi@vger.kernel.org On 2/8/2017 10:03 AM, Mark Rutland wrote: > On Wed, Feb 08, 2017 at 10:35:02AM -0600, Timur Tabi wrote: >> On 02/08/2017 10:29 AM, Ard Biesheuvel wrote: >>>>>>> + status = handle_cmdline_files(sys_table, image, cmdline_ptr, >>>>>>> + "initrd=", dram_base + SZ_512M, >>>>>>> + (unsigned long *)&initrd_addr, >>>>>>> + (unsigned long *)&initrd_size); >>>>> >>>>> So I know this patch is almost three years old, but why is there a >>>>> 512M limit on the initrd size? >>>>> >>> How do you reckon this constitutes a limit? >> >> handle_cmdline_files() calls efi_high_alloc() with that limit. I'm >> still trying to understand all the details myself, but apparently >> our firmware and initrd need to fit within the first 512MB because >> of dram_base + SZ_512M. When we change "dram_base + SZ_512M" to >> "~0", everything works. > > Just to check, how big is that initrd? 120MB right now. Probably could be optimized, but I don't think that's really the issue here. The big problem is we don't have much memory free as the platform requires that all of firmware exists in the first 512MB. On systems with a lot of devices (ie 16+ STAT drives), UEFI ends up doing a lot of allocations, which pushes the platform over the edge due to the limited memory and fragmentation of what is available. > > I guess it's possible that there simply isn't sufficient contiguous free > memory in that range, even if the initrd isn't that large. Can you share > the EFI memory map dump from booting with efi=debug? > > We originally needed to restrict this to ensure that the kernel could > map the initrd (and I think the 512M restriction specifically was > inherited from the DTB mapping restriction). Since then, we have relaxed > things in the kernel, and today Documentation/arm64/booting.txt says: > > If an initrd/initramfs is passed to the kernel at boot, it must > reside entirely within a 1 GB aligned physical memory window of > up to 32 GB in size that fully covers the kernel Image as well. > > ... so I think the EFI stub should be able to take advantage of that > relaxation. > > Ard? > > Thanks, > Mark. > -- > To unsubscribe from this list: send the line "unsubscribe linux-efi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Jeffrey Hugo Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. From mboxrd@z Thu Jan 1 00:00:00 1970 From: jhugo@codeaurora.org (Jeffrey Hugo) Date: Wed, 8 Feb 2017 10:22:36 -0700 Subject: [PATCH v3 06/10] arm64: efi: add EFI stub In-Reply-To: <20170208170305.GI15459@leverpostej> References: <1396637113-22790-1-git-send-email-leif.lindholm@linaro.org> <1396637113-22790-7-git-send-email-leif.lindholm@linaro.org> <73a460e5-98f5-86c2-142f-a9a084ee0203@codeaurora.org> <20170208170305.GI15459@leverpostej> Message-ID: <423ec003-225e-8a5f-c071-0fcbbec2679e@codeaurora.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 2/8/2017 10:03 AM, Mark Rutland wrote: > On Wed, Feb 08, 2017 at 10:35:02AM -0600, Timur Tabi wrote: >> On 02/08/2017 10:29 AM, Ard Biesheuvel wrote: >>>>>>> + status = handle_cmdline_files(sys_table, image, cmdline_ptr, >>>>>>> + "initrd=", dram_base + SZ_512M, >>>>>>> + (unsigned long *)&initrd_addr, >>>>>>> + (unsigned long *)&initrd_size); >>>>> >>>>> So I know this patch is almost three years old, but why is there a >>>>> 512M limit on the initrd size? >>>>> >>> How do you reckon this constitutes a limit? >> >> handle_cmdline_files() calls efi_high_alloc() with that limit. I'm >> still trying to understand all the details myself, but apparently >> our firmware and initrd need to fit within the first 512MB because >> of dram_base + SZ_512M. When we change "dram_base + SZ_512M" to >> "~0", everything works. > > Just to check, how big is that initrd? 120MB right now. Probably could be optimized, but I don't think that's really the issue here. The big problem is we don't have much memory free as the platform requires that all of firmware exists in the first 512MB. On systems with a lot of devices (ie 16+ STAT drives), UEFI ends up doing a lot of allocations, which pushes the platform over the edge due to the limited memory and fragmentation of what is available. > > I guess it's possible that there simply isn't sufficient contiguous free > memory in that range, even if the initrd isn't that large. Can you share > the EFI memory map dump from booting with efi=debug? > > We originally needed to restrict this to ensure that the kernel could > map the initrd (and I think the 512M restriction specifically was > inherited from the DTB mapping restriction). Since then, we have relaxed > things in the kernel, and today Documentation/arm64/booting.txt says: > > If an initrd/initramfs is passed to the kernel at boot, it must > reside entirely within a 1 GB aligned physical memory window of > up to 32 GB in size that fully covers the kernel Image as well. > > ... so I think the EFI stub should be able to take advantage of that > relaxation. > > Ard? > > Thanks, > Mark. > -- > To unsubscribe from this list: send the line "unsubscribe linux-efi" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Jeffrey Hugo Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932231AbdBHRY5 (ORCPT ); Wed, 8 Feb 2017 12:24:57 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:45460 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752850AbdBHRYy (ORCPT ); Wed, 8 Feb 2017 12:24:54 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 2A50460724 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=jhugo@codeaurora.org Subject: Re: [PATCH v3 06/10] arm64: efi: add EFI stub To: Mark Rutland , Timur Tabi References: <1396637113-22790-1-git-send-email-leif.lindholm@linaro.org> <1396637113-22790-7-git-send-email-leif.lindholm@linaro.org> <73a460e5-98f5-86c2-142f-a9a084ee0203@codeaurora.org> <20170208170305.GI15459@leverpostej> Cc: Ard Biesheuvel , linux-efi@vger.kernel.org, Catalin Marinas , lkml , Leif Lindholm , Mark Salter , "linux-arm-kernel@lists.infradead.org" From: Jeffrey Hugo Message-ID: <423ec003-225e-8a5f-c071-0fcbbec2679e@codeaurora.org> Date: Wed, 8 Feb 2017 10:22:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170208170305.GI15459@leverpostej> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/8/2017 10:03 AM, Mark Rutland wrote: > On Wed, Feb 08, 2017 at 10:35:02AM -0600, Timur Tabi wrote: >> On 02/08/2017 10:29 AM, Ard Biesheuvel wrote: >>>>>>> + status = handle_cmdline_files(sys_table, image, cmdline_ptr, >>>>>>> + "initrd=", dram_base + SZ_512M, >>>>>>> + (unsigned long *)&initrd_addr, >>>>>>> + (unsigned long *)&initrd_size); >>>>> >>>>> So I know this patch is almost three years old, but why is there a >>>>> 512M limit on the initrd size? >>>>> >>> How do you reckon this constitutes a limit? >> >> handle_cmdline_files() calls efi_high_alloc() with that limit. I'm >> still trying to understand all the details myself, but apparently >> our firmware and initrd need to fit within the first 512MB because >> of dram_base + SZ_512M. When we change "dram_base + SZ_512M" to >> "~0", everything works. > > Just to check, how big is that initrd? 120MB right now. Probably could be optimized, but I don't think that's really the issue here. The big problem is we don't have much memory free as the platform requires that all of firmware exists in the first 512MB. On systems with a lot of devices (ie 16+ STAT drives), UEFI ends up doing a lot of allocations, which pushes the platform over the edge due to the limited memory and fragmentation of what is available. > > I guess it's possible that there simply isn't sufficient contiguous free > memory in that range, even if the initrd isn't that large. Can you share > the EFI memory map dump from booting with efi=debug? > > We originally needed to restrict this to ensure that the kernel could > map the initrd (and I think the 512M restriction specifically was > inherited from the DTB mapping restriction). Since then, we have relaxed > things in the kernel, and today Documentation/arm64/booting.txt says: > > If an initrd/initramfs is passed to the kernel at boot, it must > reside entirely within a 1 GB aligned physical memory window of > up to 32 GB in size that fully covers the kernel Image as well. > > ... so I think the EFI stub should be able to take advantage of that > relaxation. > > Ard? > > Thanks, > Mark. > -- > To unsubscribe from this list: send the line "unsubscribe linux-efi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Jeffrey Hugo Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.