On Tue, 19 Sep 2017 10:59:51 -0000 "Laszlo Ersek \(Red Hat\)" <ler...@redhat.com> wrote:
> Thanks, Gerd, for the CC -- I agree, this commit (208fa0e43645) almost > certainly breaks the VBE Shim. Displaying the patch with a bit larger > context, > > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c > > index 22e16031b03b..59435390ba62 100644 > > --- a/hw/i386/pc.c > > +++ b/hw/i386/pc.c > > @@ -1442,8 +1442,11 @@ void pc_memory_init(PCMachineState *pcms, > > > > option_rom_mr = g_malloc(sizeof(*option_rom_mr)); > > memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE, > > &error_fatal); > > + if (pcmc->pci_enabled) { > > + memory_region_set_readonly(option_rom_mr, true); > > + } > > memory_region_add_subregion_overlap(rom_memory, > > PC_ROM_MIN_VGA, > > option_rom_mr, > > 1); looking at it more, question is why do we have a separate piece of ram mapped here that overlays system ram. Can we remove this memory region and let guest use underling initial memory? > > and PC_ROM_MIN_VGA is #defined as 0xc0000 in "include/hw/loader.h". > > OVMF places the VBE Shim into the C segment, and points the 0x10 > interrupt vector at it. See "OvmfPkg/QemuVideoDxe/VbeShim.c", function > InstallVbeShim(): > > > SegmentC = 0xC0000; > > > > [...] > > > > // > > // Put the shim in place first. > > // > > Pam1Address = PCI_LIB_ADDRESS (0, 0, 0, 0x5A); > > // > > // low nibble covers 0xC0000 to 0xC3FFF > > // high nibble covers 0xC4000 to 0xC7FFF > > // bit1 in each nibble is Write Enable > > // bit0 in each nibble is Read Enable > > // > > Pam1 = PciRead8 (Pam1Address); > > PciWrite8 (Pam1Address, Pam1 | (BIT1 | BIT0)); > > > > // > > // We never added memory space during PEI or DXE for the C segment, so we > > // don't need to (and can't) allocate from there. Also, guest operating > > // systems will see a hole in the UEFI memory map there. > > // > > SegmentCPages = 4; > > > > ASSERT (sizeof mVbeShim <= EFI_PAGES_TO_SIZE (SegmentCPages)); > > CopyMem ((VOID *)(UINTN)SegmentC, mVbeShim, sizeof mVbeShim); > > > > [...] > > > > // > > // Clear Write Enable (bit1), keep Read Enable (bit0) set > > // > > PciWrite8 (Pam1Address, (Pam1 & ~BIT1) | BIT0); > > > > // > > // Second, point the Int10h vector at the shim. > > // > > Int0x10->Segment = (UINT16) ((UINT32)SegmentC >> 4); > > Int0x10->Offset = (UINT16) ((UINTN) (VbeModeInfo + 1) - SegmentC); > -- 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