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

[Laszlo Ersek \(Red Hat\)]

What I mentioned earlier was not that SeaBIOS would break.

Instead, I said that building OVMF, with the SeaBIOS CSM (Compatibility
Support Module) embedded into it, would break, exactly the same way as
the VBE Shim.

Quoting the CSM Spec from Intel: "The CSM provides compatibility support
between the Framework and traditional, legacy BIOS code and allows
booting a traditional OS or booting an EFI OS off a device that requires
a traditional option ROM (OpROM)."

https://github.com/tianocore/tianocore.github.io/wiki/Compatibility-
Support-Module

Upstream edk2 contains no such module out of the box. However, SeaBIOS
has been extended with a build target (CONFIG_CSM) that produces such a
binary. This binary can be then embedded in the edk2 source tree (see
"OvmfPkg/Csm/Csm16/ReadMe.txt"), and then OVMF can be built with -D
CSM_ENABLE.

This will allow OVMF to boot legacy OSes, and those OSes will think they
are being booted on a legacy BIOS machine.

While the SeaBIOS CSM itself is provided by the SeaBIOS project, the
infrastructure that sets it up under UEFI comes from edk2. The two
important drivers are -- built into OVMF only with -D CSM_ENABLE --:

- IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf

- IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf

The former driver (LegacyBiosDxe) needs write access to the memory area
at 0xc0000, so that it can install legacy PCI option ROMs. The service
it provides is called "EFI_LEGACY_BIOS_PROTOCOL.InstallPciRom"; it loads
a traditional OpROM into traditional OpROM address space (0xC0000 to
0xFFFFF region).

The latter driver (VideoDxe) asks the former driver to install such an
option ROM (for video services) from the PCI ROM BAR.

Therefore, if the area at 0xc0000 is unwriteable for the guest, then
neither the VBE Shim, nor its alternative -- namely the full-blown
SeaBIOS CSM -- can function in OVMF.

-- 
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