qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [Bug 1715700] Re: Windows 7 guest won't boot on qemu 2.10 (


From: Laszlo Ersek \(Red Hat\)
Subject: [Qemu-devel] [Bug 1715700] Re: Windows 7 guest won't boot on qemu 2.10 (works on 2.9)
Date: Tue, 19 Sep 2017 11:58:29 -0000

Re: comment 14, "is there a way to fix vbeshim instead of reverting RO
limitation that commit introduced?":

I don't think so; please see my earlier comments 15 and 17. To
elaborate:

If a user wants to boot Windows 7 on OVMF, they have *three* options:

(1) Build the SeaBIOS CSM (CONFIG_CSM=y), and embed it into OVMF, like
described above. Then, boot Windows 7 in *Legacy Mode*.

--> Windows 7 will think that it runs on a plain BIOS machine. The VBE
Services will be provided to Windows 7 by (a) the edk2 CSM
infrastructure, (b) the SeaBIOS CSM, and (c) the VGABIOS PCI oprom
together.

(2) Build the SeaBIOS CSM (CONFIG_CSM=y), and embed it into OVMF, like
described above. Then, boot Windows 7 in *UEFI Mode*.

--> Windows 7 will think that it runs on a UEFI machine, *but* because
Windows 7 has a bug, it will want to invoke VBE services nonetheless.
The VBE Services will be provided to Windows 7 by (a) the edk2 CSM
infrastructure, (b) the SeaBIOS CSM, and (c) the VGABIOS PCI oprom
together.

(3) Build OVMF without the SeaBIOS CSM, then boot Windows 7 in UEFI
Mode.

--> Windows 7 will think that it runs on a UEFI machine, *but* because
Windows 7 has a bug, it will want to invoke VBE services nonetheless.
The VBE Services will be provided to Windows 7 by the VBE Shim that OVMF
installs during boot.


Option #1 and option #2 no longer work because the CSM infrastructure in edk2 
needs to be able to write 0xc0000.

Option #3 no longer works because OVMF needs to put the VBE Shim into
place at 0xc0000.


Basically, Windows 7 wants to find the VBE services at 0xc0000, regardless of 
the method that it is booted with, ie. Legacy or UEFI. (As I said, this is a 
Windows 7 bug.) If that memory area is not writeable to the guest, then OVMF 
cannot satisfy the (buggy) Windows 7 requirement, using either of options #1, 
#2 or #3.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1715700

Title:
  Windows 7 guest won't boot on qemu 2.10 (works on 2.9)

Status in QEMU:
  New

Bug description:
  Qemu version: 2.10 stable.
  Guest: Windows 7 SP1 x64, virtio drivers are already installed in the guest.
  Command line:
  qemu-system-x86_64 \
      -nodefaults \
      -nodefconfig \
      -machine type=q35,accel=kvm \
      -enable-kvm \
      -cpu host \
      -m 2048 \
      -vga virtio \
      -boot menu=on \
      -smbios file=/path/dmidecode_BIOS.bin \
      -acpitable file=/path/acpi_slic.bin \
      -bios /path/OVMF_CODE.fd \
      -net none \
      -drive if=virtio,media=disk,file=/media/win7.qcow2 \
      -device pcie-root-port \
      -device ich9-usb-ehci1 \
      -device ich9-usb-uhci1 \
      -device ich9-usb-uhci2 \
      -device ich9-usb-uhci3

  Windows hangs at boot with waving flag screen (flag doesn't freeze,
  keeps waving indefinitely). Same command line boots fine with Qemu
  2.9. I tried changing machine type to pc-q35-2.9 - same result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1715700/+subscriptions



reply via email to

[Prev in Thread] Current Thread [Next in Thread]