I'd also like to mention that, when we originally worked on the VBE Shim, I tried to put it elsewhere. Obviously it has to be pointed-to by a real mode interrupt vector, which limits quite a bit where it can go at all; the point is that I tried to put it into low *RAM* (under 640KB).
It didn't work. Windows 7 would only accept the VBE Shim when it existed in the C segment, i.e. where a VGA option ROM would normally be located. This is just to say that moving the VBE Shim out of the C segment (into real-mode addressible RAM) will not work. The symptom described in the original report is likely due to - Windows following the 0x10 interrupt vector (from page 0) to the C segment, - copying a bunch of zeros into its real mode emulator from the C segment (where now no actual VBE code can be found), - and then seeing no results when the real mode emulator executes the zeros. -- 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
