[Bug 211746] [Hyper-V] UEFI VM can't boot from the iso installation disk

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746

--- Comment #9 from Dexuan Cui <decui at microsoft.com> ---
(In reply to Marcel Moolenaar from comment #6)

Differences between the maps are:

1) In the first red rectangle, we can see 48MB memory (0x3000 pages) is
allocated from ConvventionalMemory to LoaderData and this is the expected
correct behavior.

2) In the second red rectangle, we can see 4 pages are allocated, probably by
the firmmare itself. I guess we can ignore this.

3) No other difference except the above.

So, Hyper-V's AllocatePages should be correct. :-)


But there is indeed some BootServicesData memory starting at 0x2f73000 with
0x118d pages (i.e. starting at 47.449 MB with the length == 17.55MB)!!!

"elf64_exec() -> trampoline() -> efi_copy_finish -> *dst++ = *src++;" tries to
overwrite the memory between 2MB and 2+48=50MB, and we get the crash -- I guess
Hyper-V has some mechanism to prevent the guest from writing into that
BootServideData memory block.

With STAGE_PAGES <= 45MB, we don't touch that BootServiceData memory block due
to the fact 2+45 < 47.449 and hence we don't get the crash.

Now, it looks to me this is a bug of FreeBSD?

It looks the hardcoded macro for the 2MB kernel base is LOADER_ADDRESS. I guess
it's not easy to make it a runtime dynamic value, but we should have a long
term plan to fix this.

And can we have a short term workaround for Hyper-V?
e.g. making STAGE_PAGES a dynamic variable and using 45MB if the loader
detecets the underlying hypervisor is Hyper-V??? :-)

Thanks Marcel for the effective help and let's brainstorm.

-- 
You are receiving this mail because:
You are the assignee for the bug.