From owner-freebsd-stable@freebsd.org Tue May 16 16:20:39 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 2978DD7074E for ; Tue, 16 May 2017 16:20:39 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01031124 for ; Tue, 16 May 2017 16:20:39 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OQ100J00ZREF400@st13p35im-asmtp002.me.com> for freebsd-stable@freebsd.org; Tue, 16 May 2017 16:20:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1494951638; bh=gbsrBr0DXK9RqRmnw9z+OVUPdR5oqfCWcHDHN3r1wrw=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=GLp7LIV9oCbh3ioeXOAJFWEhpT4psY4034iMjah78MYH6xAF98XW8Y+rRfvuzhvXs xz5rasGuCqTtQ97yIxfMBCnmruype6Ik5JYC6Z9R5B/lKJgWuuUdAw4VZtPX8YF3Ee 4HQc0FD6QJrUNXpiXdog6oRqFpRPSsxErv4N6eZOfg2djC2ZTCDyaJBBjLFZEwHDPD qt4lCHs6VEmk6fXoY9dVyUVoz2tpyRSqk0EmDrfay7L3mwuLOTEFoGVEoZIyQWZB0p yKbRgeJXjhVAV2L1B1QsRJFBykEzF9oxbuCC3axINc8yvL/6ln95PGyv4/4K8RKeh/ 7hZmR/JvC0tTg== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OQ200ATN02ATB00@st13p35im-asmtp002.me.com>; Tue, 16 May 2017 16:20:37 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-16_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705160130 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? From: Toomas Soome In-reply-to: <591B2523.6040101@omnilan.de> Date: Tue, 16 May 2017 19:20:34 +0300 Cc: freebsd-stable@freebsd.org Content-transfer-encoding: quoted-printable Message-id: <7CF3AC8F-A778-40AE-B457-9B96AE5B4719@me.com> References: <591B12C6.4040301@omnilan.de> <591B1A8B.6070803@omnilan.de> <591B1EA4.600@omnilan.de> <591B2523.6040101@omnilan.de> To: Harry Schmalzbauer X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 16:20:39 -0000 > On 16. mai 2017, at 19:13, Harry Schmalzbauer = wrote: >=20 > Bez=C3=BCglich Toomas Soome's Nachricht vom 16.05.2017 18:00 = (localtime): >>=20 >>> On 16. mai 2017, at 18:45, Harry Schmalzbauer >> > wrote: >>>=20 >>> Bez=C3=BCglich Harry Schmalzbauer's Nachricht vom 16.05.2017 17:28 = (localtime): >>>> Bez=C3=BCglich Toomas Soome's Nachricht vom 16.05.2017 16:57 = (localtime): >>>>>> On 16. mai 2017, at 17:55, Harry Schmalzbauer >>>>> > wrote: >>>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> unfortunately I had some trouble with my preferred MFS-root = setups. >>>>>> It seems EFI loader doesn't handle type md_image correctly. >>>>>>=20 >>>>>> If I load any md_image with loader invoked by gptboot or = gptzfsboot, >>>>>> 'lsmod' >>>>>> shows "elf kernel", "elf obj module(s)" and "md_image". >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Any help highly appreciated, hope Toomas doesn't mind beeing >>>>>> initially CC'd. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> -harry >>>>>=20 >>>>> The first question is, how large is the md_image and what other >>>>> modules are loaded? >>>> Thanks for your quick response. >>>>=20 >>>> The images are 50-500MB uncompressed (provided by gzip compressed = file). >>>> Small ammount of elf modules, 5, each ~50kB. >>>=20 >>> 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 >>>=20 >>> Providing md_image uncompressed doesn't change anything. >>>=20 >>> 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... >>>=20 >>> -harry >>=20 >>=20 >> 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. >>=20 >> 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. >=20 > 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? >=20 > At least now I have an idea baout the issue and an explanation why > reducing md_imgae to 100MB hasn't helped =E2=80=93 still more than = 64... >=20 > Any quick hint where to define the staging area size highly = appreciated, > fi there are no hard objections against a 768MB size. >=20 > -harry The problem is that before UEFI Boot Services are not switched off, the = memory is managed (and owned) by the firmware, and you can not write = into the random places. So you need to allocate the staging area, read = data there, switch BS off, move data into final location and start the = kernel. Alternatively, you move only the kernel into place, and let the kernel = to relocate and manage the modules and MD image. rgds, toomas