Date: Thu, 09 Mar 2017 15:25:12 +0200 From: Toomas Soome <tsoome@me.com> To: Dexuan Cui <decui@microsoft.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: input/output error @boot Message-ID: <1856AB36-8EA0-4955-AF8F-C83AB89B38A8@me.com> In-Reply-To: <MWHPR03MB266955F10E205BAB82A9F901BF210@MWHPR03MB2669.namprd03.prod.outlook.com> References: <CACnPvjLv_QhhxYvcbU44x=n0pk61xyFgUGWcTYh%2B6HaGUGJMFg@mail.gmail.com> <CACnPvjKG9NEuFDBWv=6qj5GZj4=-89qT8w75kEx-QaXjHNJzXg@mail.gmail.com> <6779d31b-a285-3002-8ecc-5738ac88df27@madpilot.net> <CANCZdfr_pTNuCpDx1rm9KcEimnhGTkCv3i2tNceAZsgrs_c%2BcQ@mail.gmail.com> <CANJ8om5Gri=%2B4Ju9BjdUONwQMW5zrzQhTpz2AzVWUKSVrSgdDA@mail.gmail.com> <CACnPvjJgLK-YtOTJOEE1Uad==pwzO39hSQ1Nk%2BnHND58EbTmvA@mail.gmail.com> <441BF371-53C4-4FE8-A39C-BFA8B25DE760@freebsd.org> <CACnPvjK%2Bb6x3SAD7Gu7uFTkx=iCm2afgt4boVquTT5BC_sF4Tg@mail.gmail.com> <MWHPR03MB2669AB5FFC455EE6BBAAE765BF2F0@MWHPR03MB2669.namprd03.prod.outlook.com> <CACnPvj%2BvrkYGR3b_CoDkORksB6ENZ5HLdzD6=ebJm1329LcfJQ@mail.gmail.com> <CACnPvj%2BQDZZjHzwU7VcsNFN784R4=gYe6qzhQb0NG0AQpov=5g@mail.gmail.com> <MWHPR03MB26699DF5E658361614D71A5EBF2E0@MWHPR03MB2669.namprd03.prod.outlook.com> <CACnPvjKW8di44raA=MxEbqfNPkYaoQ5uOCkgcT3tf1i733i1KA@mail.gmail.com> <CACnPvjJnTyxQu-4-MYB3rPWGZ4TJa%2B=niLkKdtaNTiO%2Bbw=hug@mail.gmail.com> <MWHPR03MB2669510547F2244091F676BCBF210@MWHPR03MB2669.namprd03.prod.outlook.com> <MWHPR03MB26696FB5963990FE4455609CBF210@MWHPR03MB2669.namprd03.prod.outlook.com> <63EAF6F6-D5E4-46F9-9AA1-C721DAC64C11@me.com> <MWHPR03MB266955F10E205BAB82A9F901BF210@MWHPR03MB2669.namprd03.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 9. m=C3=A4rts 2017, at 15:03, Dexuan Cui <decui@microsoft.com> = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1856AB36-8EA0-4955-AF8F-C83AB89B38A8>