Date: Sat, 02 Dec 2017 09:56:13 +0100 From: Harry Schmalzbauer <freebsd@omnilan.de> To: Toomas Soome <tsoome@me.com> Cc: freebsd-stable@freebsd.org Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? Message-ID: <5A226AAD.4010003@omnilan.de> In-Reply-To: <72722005-6EDF-44EC-A4A7-4E3CB2B0F0BD@me.com> References: <591B12C6.4040301@omnilan.de> <DD0FE9CA-48C9-4A77-81FD-8CA139D95543@me.com> <591B1A8B.6070803@omnilan.de> <591B1EA4.600@omnilan.de> <FEF74507-4A04-49DD-A763-6733E18CCE66@me.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Bezüglich Toomas Soome's Nachricht vom 29.06.2017 10:39 (localtime): > >> On 29. juuni 2017, at 11:24, Harry Schmalzbauer <freebsd@omnilan.de >> <mailto:freebsd@omnilan.de>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5A226AAD.4010003>