Date: Thu, 30 Mar 2017 12:42:29 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-virtualization@FreeBSD.org Subject: [Bug 211746] [Hyper-V] UEFI VM can't boot from the iso installation disk Message-ID: <bug-211746-27103-ersRD9WPW9@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-211746-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-211746-27103@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211746 --- Comment #33 from commit-hook@freebsd.org --- A commit references this bug: Author: dexuan Date: Thu Mar 30 12:41:21 UTC 2017 New revision: 316272 URL: https://svnweb.freebsd.org/changeset/base/316272 Log: MFC: 314547, 314770, 314828, 314891, 314956, 314962, 315235 r314547 loader.efi: reduce the size of the staging area if necessary The loader assumes physical memory in [2MB, 2MB + EFI_STAGING_SIZE) is Conventional Memory, but actually it may not, e.g. in the case of Hyper-V Generation-2 VM (i.e. UEFI VM) running on Windows Server 2012 R2 host, there is a BootServiceData memory block at the address 47.449MB and the memory is not writable. Without the patch, the loader will crash in efi_copy_finish(): see PR 211746. The patch verifies the end of the staging area, and reduces its size if necessary. This way, the loader will not try to write into the BootServiceData memory any longer. Thank Marcel Moolenaar for helping me on this issue! The patch also allocates the staging area in the first 1GB memory. See the comment in the patch for this. PR: 211746 Reviewed by: marcel, kib, sephe Approved by: sephe (mentor) Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D9686 r314770 loader.efi: fix recent UEFI-boot regression on physical machines This patch fixes my recent patch "loader.efi: reduce the size of the staging area if necessary", which causes EFI-boot failure on physical machines since Mar 2: on the host there is a 1MB LoaderData memory range, which splits the big Conventional Memory range into a small one (15MB) and a big one: the small one is too small to hold the staging area. We can actually use the LoaderData range safely, because when amd64_tramp -> efi_copy_finish() starts to run, we're almost at the very end of the efi loader code and we're going to "return" to the kernel entry, so we're pretty sure we won't access any loader data any more. For people who are interested in the details: please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211746#c22 PS, some people also reported the regression happened to FreeBSD VM running on Bhyve in EFI mode. This patch should resolve it too, though I don't have such a setup to test. Reviewed by: sephe Approved by: sephe (mentor) Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D9904 r314828 loader.efi: fix an off-by-one bug in efi_verify_staging_size() Also remove the warning message: it may not be unusual to see the memory range containing 2MB is not of EfiConventionalMemory. Sponsored by: Microsoft r314891 loader.efi: finally fix the off-by-one bug in efi_verify_staging_size= () r314828(loader.efi: fix an off-by-one bug in efi_verify_staging_size(= )) doesn't really fix the bug and this patch adds the missing part. It's a shame that I didn't make everything correct at the very beginning... Sponsored by: Microsoft r314956 loader.efi: only reduce the size of the staging area on Hyper-V Doing this on physical hosts turns out to be problematic, e.g. see comment 24 and 28 in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D2117= 46. To fix the real underlying issue correctly & thoroughly, IMO we need a relocatable kernel, but that would require a lot of complicated long term work: https://reviews.freebsd.org/D9686?id=3D25414#inline-56969 For now, let's only apply efi_verify_staging_size() to VMs running on Hyper-V, and restore the old behavior on physical machines since that has been working for people for a long period of time, though that's potentially unsafe... Sponsored by: Microsoft r314962 loader.efi: only include the machine/ header files on x86 The 2 files may not exist on other archs like aarch64 and hence we can have a build failure there. Reported by: lwhsu Sponsored by: Microsoft r315235 loader.efi: use stricter check for Hyper-V Some other hypervisors like Xen can pretend to be Hyper-V but obvious= ly they can't implement all Hyper-V features. Let's make sure we're genu= ine Hyper-V here. Also fix some minor coding style issues. PR: 211746 Sponsored by: Microsoft PR: 211746 Changes: _U stable/11/ stable/11/sys/boot/efi/loader/copy.c --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-211746-27103-ersRD9WPW9>