Date: Thu, 9 Mar 2017 13:03:46 +0000 From: Dexuan Cui <decui@microsoft.com> To: Toomas Soome <tsoome@me.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: RE: input/output error @boot Message-ID: <MWHPR03MB266955F10E205BAB82A9F901BF210@MWHPR03MB2669.namprd03.prod.outlook.com> In-Reply-To: <63EAF6F6-D5E4-46F9-9AA1-C721DAC64C11@me.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>
index | next in thread | previous in thread | raw e-mail
> From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Toomas Soome > > IMO there are multiple issues around this problem and workaround. > > First of all, to control UEFI memory allocation, the AllocatePages() has options: > > AllocateAnyPages, > AllocateMaxAddress, > AllocateAddress > > On x86, we use: > > staging = 1024*1024*1024; > status = BS->AllocatePages(AllocateMaxAddress, EfiLoaderData, > nr_pages, &staging); > > Which means: > > "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.” > > So, we are asking for an amount of memory (64MB), with condition that all the > pages should be below 1GB. > > 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. 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. If you're interested, the whole long story is in the below link. :-) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746, e.g. please see the screenshot in comment #8. > 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... > 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... > 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). > > The secondary flaw there is also about firmware. Sure, with UEFI you can have > “random” allocations and the actual control over memory is actually problem, > but to plant an “egg” in 1MB-1GB range, where you have most chances any OS > will live - IMO this is just stupid. > > 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… 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. Thanks, -- Dexuanhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MWHPR03MB266955F10E205BAB82A9F901BF210>