Re: Drop CSM support in OvmfPkg?

[Laszlo Ersek <lersek@redhat.com>]

(Adding Kevin, Gerd, David)

On 12/17/18 03:23, Ni, Ruiyu wrote:
> Hi OvmfPkg maintainers and reviewers,
> I am working on removing IntelFrameworkModulePkg and IntelFrameworkPkg. The biggest dependency now I see is the CSM components that OVMF depends on.
> So I'd like to know your opinion about how to handle this. I see two options here:
> 
>   1.  Drop CSM support in OvmfPkg.
>   2.  Create a OvmfPkg/Csm folder to duplicate all CSM components there.
> 
> What's your opinion about this?

(1) Personally I never use CSM builds of OVMF. The OVMF builds in RHEL
and Fedora also don't enable the CSM (mainly because I had found
debugging & supporting the CSM *extremely* difficult). For
virtualization, we generally recommend "use SeaBIOS directly if you need
a traditional BIOS guest".

(2) I'd be definitely unhappy about having to maintain the
platform-independent CSM components under OvmfPkg (such as
LegacyBootManagerLib, LegacyBootMaintUiLib, LegacyBiosDxe, VideoDxe).

(3) However, David and Kevin had put a *lot* of work into enabling
SeaBIOS to function as a CSM in combination with OVMF. Today, the CSM
target is a dedicated / separate "build mode" of SeaBIOS.

(4) I also think an open source CSM implementation should exist, just so
people can study it and experiment with it. The CSM specification (from
Intel) is a public document, and the edk2 code is the reference
implementation for it. Killing the reference implementation makes the
spec mostly useless. Are Intel withdrawing the spec too? (Or has that
happened already?)

In short, I think the community would benefit if someone continued to
maintain the CSM infrastructure in edk2, but personally I won't
volunteer. I also understand if Intel has no more resources for it.
Removing CSM from edk2 altogether (including OVMF) might be the natural
(albeit regrettable) result.

Thanks
Laszlo