> On 9. märts 2017, at 15:03, Dexuan Cui <de...@microsoft.com> wrote: > >> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- >> curr...@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. >
ah, right, so it already does the relocation and will get busted there, sorry, missed that:D > >> 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, > -- 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 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"