diff options
Diffstat (limited to 'results/classifier/118/all/1715700')
| -rw-r--r-- | results/classifier/118/all/1715700 | 569 |
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. + |