From owner-freebsd-current@freebsd.org Thu Mar 9 13:25:23 2017 Return-Path: Delivered-To: freebsd-current@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 55255D0280F for ; Thu, 9 Mar 2017 13:25:23 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (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 2BD1AD32 for ; Thu, 9 Mar 2017 13:25:23 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OMJ00800U8HSQ00@st13p35im-asmtp001.me.com> for freebsd-current@freebsd.org; Thu, 09 Mar 2017 13:25:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1489065916; bh=xXdsEFS4ryHjBGgCmFDBQqjDbzQ4PRQoJwkcvxXMWJg=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=JSiBN5C974s9Uo3dOeiURu5t2A1JSFInJjeC+EgScAszCBkPpU7rXicPAvsS1OK5w +Oqg8ao6YSNq7yuu98bTjsKRZlz0/hKMn8mLJyswZZ8pjfPv9nITGXXQXh4xU4N7sq AA1Dn2iH81sfbgm/3tVAamHBx9ni2bjy8BqwIg/TeyZn5WqHowSpZhC0guON207Qqw PiLla4sAs5wovQdHKteIm16b3ek7/sz4OcFBmkTWJU6qiHF+FDCdjZ/ul6WPyuvdRE EdUJ5GXnojoHf1XBPoAJiNRYwgaJmUXCigWxg/1wp6sYk35KUqlSDwAGMeOfvJAzeT +misWOEN01ufA== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OMJ00EPHUM1D810@st13p35im-asmtp001.me.com>; Thu, 09 Mar 2017 13:25:15 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-09_11:,, 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-1703090101 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: input/output error @boot From: Toomas Soome In-reply-to: Date: Thu, 09 Mar 2017 15:25:12 +0200 Cc: FreeBSD Current Content-transfer-encoding: quoted-printable Message-id: <1856AB36-8EA0-4955-AF8F-C83AB89B38A8@me.com> References: <6779d31b-a285-3002-8ecc-5738ac88df27@madpilot.net> <441BF371-53C4-4FE8-A39C-BFA8B25DE760@freebsd.org> <63EAF6F6-D5E4-46F9-9AA1-C721DAC64C11@me.com> To: Dexuan Cui X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 13:25:23 -0000 > On 9. m=C3=A4rts 2017, at 15:03, Dexuan Cui = wrote: >=20 >> From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- >> current@freebsd.org] On Behalf Of Toomas Soome >>=20 >> IMO there are multiple issues around this problem and workaround. >>=20 >> First of all, to control UEFI memory allocation, the AllocatePages() = has options: >>=20 >> AllocateAnyPages, >> AllocateMaxAddress, >> AllocateAddress >>=20 >> On x86, we use: >>=20 >> staging =3D 1024*1024*1024; >> status =3D BS->AllocatePages(AllocateMaxAddress, = EfiLoaderData, >> nr_pages, &staging); >>=20 >> Which means: >>=20 >> "Allocation requests of Type AllocateMaxAddress allocate any = available range of >> pages whose uppermost address is less than or equal to the address = pointed to >> by Memory on input.=E2=80=9D >>=20 >> So, we are asking for an amount of memory (64MB), with condition that = all the >> pages should be below 1GB. >>=20 >> And we get it. If hyper-v is in fact returning us memory from already = occupied >> area - there can be exactly one conclusion - it is bug in hyper-v. >=20 > Hyper-V has no bug here: Hyper-V doesn't return memory from already = occupied > area. The issue is: the loader here tries to write the 64MB staging = area (BTW, it's > 48MB in 10.3) into the physical memory range [2MB, 2MB+64MB) -- the = loader > assumes this range is writable. However, this is not true with Hyper-V = EFI > firmware: there is a read-only BootServicesData memory block starting = at > about 47.449MB, causing a crash in the loader. >=20 > If you're interested, the whole long story is in the below link. :-) > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211746, e.g. = please see the > screenshot in comment #8. >=20 ah, right, so it already does the relocation and will get busted there, = sorry, missed that:D >=20 >> Note, this allocation method does *not* set the starting point for = allocation, it >> can return us *any* chunk of memory of given size, below 1GB. > Yes. This can potentially cause new issues... >=20 >> So the attempt to control such allocation by size, is unfortunately = flawed - it >> really does not control the allocation. > Yes, you're correct. > The patch is flawed. I only expect (or hope) it can work around the = issues with > typical Hyper-V UEFI firmware. > In my test, it works with Hyper-V 2012 R2 and 2016. > I hope it could work in future Hyper-V too... >=20 >> Note that I have also seen AllocateAddress failures - there was = nicely available >> chunk of memory, but the firmware just did not allocate with given = address (it >> did happen with OVMF + qemu). >>=20 >> The secondary flaw there is also about firmware. Sure, with UEFI you = can have >> =E2=80=9Crandom=E2=80=9D allocations and the actual control over = memory is actually problem, >> but to plant an =E2=80=9Cegg=E2=80=9D in 1MB-1GB range, where you = have most chances any OS >> will live - IMO this is just stupid. >>=20 >> The only real solution here is to either rise the MaxAddress limit or = use >> AllocateAnyPages, get kernel loaded into the memory, and after = switching off >> the boot services and before jumping to kernel, relocate the kernel = to available >> location below 1GB=E2=80=A6 > Yes. IMO the biggest issue is that currently the kernel can't be = relocated... :-( > It's a long term work to make it relocatable, I'm afraid. >=20 > Thanks, > -- Dexuan true, and there are other systems with same issue. relocatable kernels = are not really that common even today;) anyhow, good work from your = side;) rgds, toomas