Comment 17 for bug 1715700

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.