From owner-freebsd-stable@freebsd.org Thu Jun 29 08:39:59 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 2961DD96F4A for ; Thu, 29 Jun 2017 08:39:59 +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 EE1167B698 for ; Thu, 29 Jun 2017 08:39:58 +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 <0OSA00800VTLO300@st13p35im-asmtp002.me.com> for freebsd-stable@freebsd.org; Thu, 29 Jun 2017 08:39:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1498725578; bh=IowHEC/GkSaJLdQYYgVkQTgyo79PJK4phq8dkrrlY+U=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=CEsb4VgeVeA4ofbkJWl0jbiKlMIL0Z5TOahxdipLJam12sWo8kB27pqcHkpQhBvDB 3Q5FaFErcKrB1SpH1JDr8/sEhe1Unaq8Uda/k70cKaMD5KxQp8TmPCmKIyqC7AwNVH 3eNE1HK8hWeKbsvoxHk6GAgkeDlLgMpIWw9C9mQbfjfDQ9/5U6zBAUHmnP6bKZUCLk rh3k5AOX1Y9jKeRs0VZMeCBXBKpAF94M8iniDNTbnPEqe/I4JkfzlNuiepVen49cue 7+oLsnPtaHeTXdODykeR6zwQdjZ/J6Td+cf/ThY7y8i46sWhyjL/8E8GTc3zdcRDmg 99xtUhCnjg39w== 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 <0OSA00NOGW1Y7Q20@st13p35im-asmtp002.me.com>; Thu, 29 Jun 2017 08:39:38 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-29_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1706290140 From: Toomas Soome Message-id: <72722005-6EDF-44EC-A4A7-4E3CB2B0F0BD@me.com> MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? Date: Thu, 29 Jun 2017 11:39:33 +0300 In-reply-to: <5954B93C.8060101@omnilan.de> Cc: freebsd-stable@freebsd.org To: Harry Schmalzbauer 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> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Thu, 29 Jun 2017 08:39:59 -0000 > On 29. juuni 2017, at 11:24, Harry Schmalzbauer = wrote: >=20 > Bez=C3=BCglich Harry Schmalzbauer's Nachricht vom 16.05.2017 18:26 = (localtime): >> B > =E2=80=A6 >>>>> 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. >>>> 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, >> Hmm, I've been expecting something like that (owend by firmware) ;-) >>=20 >> So I'll stay with CSM for now, and will happily be an early adopter = if >> you need someone to try anything (-stable mergable). >=20 > Toomas, thanks for your help so far! I'm just curious if there's news = on > this. > Was there a decision made whether kernel should be utilized to = relocate > the MD image modules or the loader should be extended to handle > (x-)large staging areas? >=20 > I'd like to switch back to UEFI booting for various reasons (most > priority has consistency), but can't since it breaks md-rootfs with = that > machine (the other run ESXi still). >=20 > If there's anything to test, please let me know. >=20 > Thanks, >=20 > -harry 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. rgds, toomas=