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

Thu Mar 30 12:51:57 UTC 2017

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

--- Comment #34 from commit-hook at freebsd.org ---
A commit references this bug:

Author: dexuan
Date: Thu Mar 30 12:51:44 UTC 2017
New revision: 316273
URL: https://svnweb.freebsd.org/changeset/base/316273

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.

      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=211746#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=211746.

      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=25414#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 obviously
      they can't implement all Hyper-V features. Let's make sure we're genuine
      Hyper-V here.

      Also fix some minor coding style issues.

      Sponsored by:     Microsoft

  PR:           211746

Changes:
_U  stable/10/
  stable/10/sys/boot/efi/loader/copy.c

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