Comment 20 for bug 1715700

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.