From owner-freebsd-stable@freebsd.org Mon Apr 8 06:45:08 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6D6B15767C2 for ; Mon, 8 Apr 2019 06:45:07 +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 859F28A560 for ; Mon, 8 Apr 2019 06:45:01 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id x386iw49045652; Mon, 8 Apr 2019 08:44:58 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 4BA53A8D; Mon, 8 Apr 2019 08:44:58 +0200 (CEST) Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? From: Harry Schmalzbauer To: Toomas Soome Cc: freebsd-stable@freebsd.org 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> Organization: OmniLAN Message-ID: <30f7b617-1814-ad21-a445-a62758150dc3@omnilan.de> Date: Mon, 8 Apr 2019 08:44:57 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <591B284B.6070204@omnilan.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Mon, 08 Apr 2019 08:44:58 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-Rspamd-Queue-Id: 859F28A560 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of freebsd@omnilan.de designates 2a00:e10:2800::a130 as permitted sender) smtp.mailfrom=freebsd@omnilan.de X-Spamd-Result: default: False [-5.66 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[omnilan.de]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[mx0.gentlemail.de]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.85)[-0.851,0]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[me.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:25074, ipnet:2a00:e10:2800::/64, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-3.50)[ip: (-9.18), ipnet: 2a00:e10:2800::/64(-4.66), asn: 25074(-3.67), country: DE(-0.01)] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 06:45:08 -0000 Am 16.05.2017 um 18:26 schrieb Harry Schmalzbauer: > Bezüglich Toomas Soome's Nachricht vom 16.05.2017 18:20 (localtime): >>> On 16. mai 2017, at 19:13, Harry Schmalzbauer wrote: >>> >>> Bezüglich Toomas Soome's Nachricht vom 16.05.2017 18:00 (localtime): >>>>> On 16. mai 2017, at 18:45, Harry Schmalzbauer >>>> > wrote: >>>>> >>>>> Bezüglich Harry Schmalzbauer's Nachricht vom 16.05.2017 17:28 (localtime): >>>>>> Bezüglich Toomas Soome's Nachricht vom 16.05.2017 16:57 (localtime): >>>>>>>> On 16. mai 2017, at 17:55, Harry Schmalzbauer >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> unfortunately I had some trouble with my preferred MFS-root setups. >>>>>>>> It seems EFI loader doesn't handle type md_image correctly. >>>>>>>> >>>>>>>> If I load any md_image with loader invoked by gptboot or gptzfsboot, >>>>>>>> 'lsmod' >>>>>>>> shows "elf kernel", "elf obj module(s)" and "md_image". >>>>>>>> >>>>>>>> Using the same loader.conf, but EFI loader, the md_image-file is >>>>>>>> prompted and sems to be loaded, but not registered. There's no >>>>>>>> md_image >>>>>>>> with 'lsmod', hence it's not astonsihing that kernel doesn't attach md0 >>>>>>>> so booting fails since there's no rootfs. >>>>>>>> >>>>>>>> Any help highly appreciated, hope Toomas doesn't mind beeing >>>>>>>> initially CC'd. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -harry >>>>>>> The first question is, how large is the md_image and what other >>>>>>> modules are loaded? >>>>>> Thanks for your quick response. >>>>>> >>>>>> The images are 50-500MB uncompressed (provided by gzip compressed file). >>>>>> Small ammount of elf modules, 5, each ~50kB. >>>>> On the real HW, there's vmm and some more: >>>>> Id Refs Address Size Name >>>>> 1 46 0xffffffff80200000 16M kernel >>>>> 2 1 0xffffffff8121d000 86K unionfs.ko >>>>> 3 1 0xffffffff81233000 3.1M zfs.ko >>>>> 4 2 0xffffffff81545000 51K opensolaris.ko >>>>> 5 7 0xffffffff81552000 279K usb.ko >>>>> 6 1 0xffffffff81598000 67K ukbd.ko >>>>> 7 1 0xffffffff815a9000 51K umass.ko >>>>> 8 1 0xffffffff815b6000 46K aesni.ko >>>>> 9 1 0xffffffff815c3000 54K uhci.ko >>>>> 10 1 0xffffffff815d1000 65K ehci.ko >>>>> 11 1 0xffffffff815e2000 15K cc_htcp.ko >>>>> 12 1 0xffffffff815e6000 3.4M vmm.ko >>>>> 13 1 0xffffffffa3a21000 12K ums.ko >>>>> 14 1 0xffffffffa3a24000 9.1K uhid.ko >>>>> >>>>> Providing md_image uncompressed doesn't change anything. >>>>> >>>>> Will deploy a /usr separated rootfs, which is only ~100MB uncompressed >>>>> and see if that changes anything. >>>>> That's all I can provide, code is far beyond my knowledge... >>>>> >>>>> -harry >>>> >>>> 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) ;-) > > So I'll stay with CSM for now, and will happily be an early adopter if > you need someone to try anything (-stable mergable). Hello Toomas, thanks for your ongoing FreeBSD commits, saw your recent libstand improvements and the efiloader commit. Which remembers me nagging the skilled ones for my unmet needs ;-) I guess nobody had time to look at the MFS-root limitation with EFI vs. BIOS. If you have any news/plans, please share. The ability to boot via EFI gives a much better console experience/usability for admins, but on MFS-root system, I'm still forced to use the old loader path, because of the 64MB size limit. Do you think there's a chance that this will be resolved for FreeBSD? Thanks, -harry