other: 0.980
mistranslation: 0.979
device: 0.972
instruction: 0.970
boot: 0.969
assembly: 0.969
graphic: 0.965
semantic: 0.965
vnc: 0.963
KVM: 0.960
socket: 0.958
network: 0.954

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

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.

Hi,
  There's a good chance this is the same as lp 1714331 - fixed by a newer OVMF.


Compiled latest OVMF from git (ea21f1d), used it in "-bios" line - same result. What else can I try?

On Thu, 07 Sep 2017 19:34:37 -0000
Aleksei Kovura <email address hidden> wrote:

> Compiled latest OVMF from git (ea21f1d), used it in "-bios" line - same
> result. What else can I try?
Bisecting 2.9 -> 2.10 might point out offending commit


Ok, so I cloned from github and am bisecting like this (it's been a while, correct me if I'm wrong):
$ git bisect start
$ git bisect bad 1ab5eb4efb91a3d4569b0df6e824cc08ab4bd8ec # 2.10.0 stable commit
$ git bisect good 359c41abe32638adad503e386969fa428cecff52 # 2.9.0 stable commit
Bisecting: 1426 revisions left to test after this (roughly 11 steps)
[269c20b2bbd2aa8531e0cdc741fb166f290d7a2b] tests/qdict: check more get_try_int() cases
$ mkdir -p bin/269c20b2bbd2aa8531e0cdc741fb166f290d7a2b
$ cd bin/269c20b2bbd2aa8531e0cdc741fb166f290d7a2b
$ ../../configure --target-list=x86_64-softmmu --python=/usr/bin/python2 --enable-debug

Compilation fails with this (full log here https://pastebin.com/aUYyE6Bb):

  CC      block/block-backend.o
/media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c: In function ‘blkdebug_refresh_filename’:
/media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c:843:31: error: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4086 [-Werror=format-truncation=]
                  "blkdebug:%s:%s", s->config_file ?: "",
                               ^~
/media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c:842:9: note: ‘snprintf’ output 11 or more bytes (assuming 4106) into a destination of size 4096
         snprintf(bs->exact_filename, sizeof(bs->exact_filename),
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                  "blkdebug:%s:%s", s->config_file ?: "",
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                  bs->file->bs->exact_filename);
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [/media/usb465gb_232gb_NTFS/compile/qemu/rules.mak:66: block/blkdebug.o] Error 1
make: *** Waiting for unfinished jobs....
/media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c: In function ‘blkverify_refresh_filename’:
/media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c:305:29: error: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4086 [-Werror=format-truncation=]
                  "blkverify:%s:%s",
                             ^~
/media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c:304:9: note: ‘snprintf’ output between 12 and 8202 bytes into a destination of size 4096
         snprintf(bs->exact_filename, sizeof(bs->exact_filename),
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                  "blkverify:%s:%s",
                  ~~~~~~~~~~~~~~~~~~
                  bs->file->bs->exact_filename,
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                  s->test_file->bs->exact_filename);
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [/media/usb465gb_232gb_NTFS/compile/qemu/rules.mak:66: block/blkverify.o] Error 1

Did I hit a commit with a broken build or something? What to do next?

* Aleksei Kovura (<email address hidden>) wrote:
> Ok, so I cloned from github and am bisecting like this (it's been a while, correct me if I'm wrong):
> $ git bisect start
> $ git bisect bad 1ab5eb4efb91a3d4569b0df6e824cc08ab4bd8ec # 2.10.0 stable commit
> $ git bisect good 359c41abe32638adad503e386969fa428cecff52 # 2.9.0 stable commit
> Bisecting: 1426 revisions left to test after this (roughly 11 steps)
> [269c20b2bbd2aa8531e0cdc741fb166f290d7a2b] tests/qdict: check more get_try_int() cases
> $ mkdir -p bin/269c20b2bbd2aa8531e0cdc741fb166f290d7a2b
> $ cd bin/269c20b2bbd2aa8531e0cdc741fb166f290d7a2b
> $ ../../configure --target-list=x86_64-softmmu --python=/usr/bin/python2 --enable-debug
> 
> Compilation fails with this (full log here
> https://pastebin.com/aUYyE6Bb):
> 
>   CC      block/block-backend.o
> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c: In function ‘blkdebug_refresh_filename’:
> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c:843:31: error: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4086 [-Werror=format-truncation=]
>                   "blkdebug:%s:%s", s->config_file ?: "",
>                                ^~
> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c:842:9: note: ‘snprintf’ output 11 or more bytes (assuming 4106) into a destination of size 4096
>          snprintf(bs->exact_filename, sizeof(bs->exact_filename),
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>                   "blkdebug:%s:%s", s->config_file ?: "",
>                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>                   bs->file->bs->exact_filename);
>                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> make: *** [/media/usb465gb_232gb_NTFS/compile/qemu/rules.mak:66: block/blkdebug.o] Error 1
> make: *** Waiting for unfinished jobs....
> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c: In function ‘blkverify_refresh_filename’:
> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c:305:29: error: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4086 [-Werror=format-truncation=]
>                   "blkverify:%s:%s",
>                              ^~
> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c:304:9: note: ‘snprintf’ output between 12 and 8202 bytes into a destination of size 4096
>          snprintf(bs->exact_filename, sizeof(bs->exact_filename),
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>                   "blkverify:%s:%s",
>                   ~~~~~~~~~~~~~~~~~~
>                   bs->file->bs->exact_filename,
>                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>                   s->test_file->bs->exact_filename);
>                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> make: *** [/media/usb465gb_232gb_NTFS/compile/qemu/rules.mak:66: block/blkverify.o] Error 1
> 
> Did I hit a commit with a broken build or something? What to do next?

It's just the newer compiler is more fussy than the old one so when you
bisect you're not getting fixes for newer compilers.   You can pass
flags to the configure to use extra clfgas to turn this particular
warning off.

Dave

> -- 
> 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
> 
--
Dr. David Alan Gilbert / <email address hidden> / Manchester, UK


The newer GCC compilers are more fussy - just add '--disable-werror' when running 'configure' to make it ignore the warning

Bisected. Good thing Igor is already here :)

208fa0e43645edd0b0d8f838857dfc79daff40a8 is the first bad commit
commit 208fa0e43645edd0b0d8f838857dfc79daff40a8
Author: Igor Mammedov <email address hidden>
Date:   Fri Jul 28 11:09:05 2017 +0200

    pc: make 'pc.rom' readonly when machine has PCI enabled


Just did a test to be sure: pulled latest git (a9158a5cba955b79d580a252cc58ff44d154e370) - guest didn't launch. Reverted 208fa0e43645edd0b0d8f838857dfc79daff40a8 - guest launched successfully.

Can someone please take a look at this? I don't want to get stuck at 2.9.0 :)

Added Imammedo to this lp.

Igor asked to add Gerd.

could be this commit breaks vbeshim ...

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

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


I'm not sure if I mentioned this before, but launchpad is an *abomination*.

On Tue, 19 Sep 2017 10:39:00 -0000
Gerd Hoffmann <email address hidden> wrote:

> could be this commit breaks vbeshim ...
> 

is there a way to fix vbeshim instead of reverting RO limitation that commit introduced?


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.

On Tue, 19 Sep 2017 10:39:00 -0000
Gerd Hoffmann <email address hidden> wrote:

> could be this commit breaks vbeshim ...
> 

Did a bit of testing: w7 iso boots to install screen with seabios but
stuck at win boot logo with ovmf.

I've heard (maybe wrongly) that seabios would also break in that case.



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.

On Tue, 19 Sep 2017 10:59:51 -0000
"Laszlo Ersek \(Red Hat\)" <email address hidden> 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);  
> 



ovmf seems to not touch pam configuration, so rom remains mapped.
seabios in contrast maps the address range to ram instead.
IIRC ovmf does that too in CSM mode.
So, yes, probably this is fixable in ovmf.

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.

On 09/19/17 13:49, Gerd Hoffmann wrote:
> ovmf seems to not touch pam configuration, so rom remains mapped.

I don't understand; the code that I quoted above -- and that LaunchPad
messed up -- explicitly changes the PAM registers:

  //
  // 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));

...

  //
  // Clear Write Enable (bit1), keep Read Enable (bit0) set
  //
  PciWrite8 (Pam1Address, (Pam1 & ~BIT1) | BIT0);

> seabios in contrast maps the address range to ram instead.
> IIRC ovmf does that too in CSM mode.
> So, yes, probably this is fixable in ovmf.

I don't see how.

Thanks
Laszlo


Ahh, wait, now I remember something -- the PAM registers are at a different location on Q35!!!

If that's what's wrong, then it is indeed an OVMF bug. Let me see if I can write a patch.



Indeed the CSM platform support had the same error one and half years ago, see:

https://github.com/tianocore/edk2/commit/db27e9f3d8f0

Thank you, Gerd, for the hint!

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

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

Well, option #2 works for me.



On 09/19/17 14:38, Gerd Hoffmann wrote:
>> (2) Build the SeaBIOS CSM (CONFIG_CSM=y), and embed it into OVMF,
>> like described above. Then, boot Windows 7 in *UEFI Mode*.
> 
>> Option #1 and option #2 no longer work because the CSM infrastructure
>> in edk2 needs to be able to write 0xc0000.
> 
> Well, option #2 works for me.
> 

Correct, and that's because edk2 commit db27e9f3d8f0 fixed the PAM
register offsets for Q35, in the CSM platform support. At that time we
missed that the same should be done in the VBE Shim as well.

I'm going to do it for the VBE Shim now.

(I'm pretty sure UEFI Windows 7 boots fine with the VBE Shim right now,
on QEMU 2.10, if the machine type is i440fx, not q35.)

Thanks for the help!
Laszlo


Posted:

[edk2] [PATCH 0/3] OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly

https://lists.01.org/pipermail/edk2-devel/2017-September/014898.html

I CC'd Aleksei on the series, but testing is welcome from anyone. (The cover letter at the link contains a git fetch URL.)

edk2 commit range: b68c793144e8..947f3737abf6.

See also LP#1725560.

I assume this has been completely fixed in edk2, so I'm closing this QEMU bug now.