From owner-freebsd-stable@freebsd.org Sat Dec 2 08:56:18 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ACBFADF8455 for ; Sat, 2 Dec 2017 08:56:18 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5ECF866A90 for ; Sat, 2 Dec 2017 08:56:17 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id vB28uE6a049018; Sat, 2 Dec 2017 09:56:14 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 28EC6DA2; Sat, 2 Dec 2017 09:56:14 +0100 (CET) Message-ID: <5A226AAD.4010003@omnilan.de> Date: Sat, 02 Dec 2017 09:56:13 +0100 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Toomas Soome CC: freebsd-stable@freebsd.org Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? References: <591B12C6.4040301@omnilan.de> <591B1A8B.6070803@omnilan.de> <591B1EA4.600@omnilan.de> <591B2523.6040101@omnilan.de> <7CF3AC8F-A778-40AE-B457-9B96AE5B4719@me.com> <591B284B.6070204@omnilan.de> <5954B93C.8060101@omnilan.de> <72722005-6EDF-44EC-A4A7-4E3CB2B0F0BD@me.com> In-Reply-To: <72722005-6EDF-44EC-A4A7-4E3CB2B0F0BD@me.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Sat, 02 Dec 2017 09:56:14 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2017 08:56:18 -0000 Bezüglich Toomas Soome's Nachricht vom 29.06.2017 10:39 (localtime): > >> On 29. juuni 2017, at 11:24, Harry Schmalzbauer > > wrote: >> >> Bezüglich Harry Schmalzbauer's Nachricht vom 16.05.2017 18:26 (localtime): >>> B >> … >>>>>> The issue is, that current UEFI implementation is using 64MB staging >>>>>> memory for loading the kernel and modules and files. When the boot is >>>>>> called, the relocation code will put the bits from staging area >>>>>> into the >>>>>> final places. The BIOS version does not need such staging area, >>>>>> and that >>>>>> will explain the difference. >>>>>> >>>>>> I actually have different implementation to address the same problem, >>>>>> but thats for illumos case, and will need some work to make it usable >>>>>> for freebsd; the idea is actually simple - allocate staging area per >>>>>> loaded file and relocate the bits into the place by component, not as >>>>>> continuous large chunk (this would also allow to avoid the mines like >>>>>> planted by hyperv;), but right now there is no very quick real >>>>>> solution >>>>>> other than just build efi loader with larger staging size. >>>>> Ic, thanks for the explanation. >>>>> While not aware about the purpose of the staging area nor the >>>>> consequences of enlarging it, do you think it's feasable increasing it >>>>> to 768Mib? >>>>> >>>>> At least now I have an idea baout the issue and an explanation why >>>>> reducing md_imgae to 100MB hasn't helped – still more than 64... >>>>> >>>>> Any quick hint where to define the staging area size highly >>>>> appreciated, >>>>> fi there are no hard objections against a 768MB size. >>>>> >>>>> -harry >>>> The problem is that before UEFI Boot Services are not switched off, >>>> the memory is managed (and owned) by the firmware, >>> Hmm, I've been expecting something like that (owend by firmware) ;-) >>> … > There has not been too much activities about this topic, except some > discussions. But it is quite clear that this change has to be handled by > the loader in first place - as we need to get the data in safe location; > now of course there is secondary part as well - it may be that kernel > would need some work as well, depending on how the md image(s) are to be > handled in relation to memory maps. Hello Toomas, unfortunately my skills don't allow me to make this happen myself :-( But since almost every production system here is MFS_ROOT based, I'm awfully missing the UEFI boot feature, especially on those where I have to do work via vt(4) from time to time, which would be a lot easier if vt_efi was usable instead of vt_vga :-) Can you estimate if someone has intentions/interest/time to implement the missing extensions in boot and kernel resp. the timeframe? Thanks, -harry