add 18th iteration of classifier

1 files changed, 569 insertions, 0 deletions

diff --git a/results/classifier/118/all/1715700 b/results/classifier/118/all/1715700
new file mode 100644
index 00000000..512c8e0f
--- /dev/null
+++ b/results/classifier/118/all/1715700
@@ -0,0 +1,569 @@
+user-level: 0.983
+register: 0.980
+mistranslation: 0.979
+permissions: 0.977
+files: 0.975
+risc-v: 0.975
+virtual: 0.975
+arm: 0.975
+device: 0.972
+debug: 0.970
+boot: 0.969
+assembly: 0.969
+TCG: 0.968
+VMM: 0.968
+performance: 0.966
+architecture: 0.966
+graphic: 0.965
+semantic: 0.965
+PID: 0.964
+x86: 0.963
+vnc: 0.963
+kernel: 0.963
+peripherals: 0.963
+ppc: 0.962
+KVM: 0.960
+socket: 0.958
+network: 0.954
+hypervisor: 0.951
+i386: 0.939
+
+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.
+