Re: Drop CSM support in OvmfPkg?

[Gerd Hoffmann <kraxel@redhat.com>]

On Mon, Dec 17, 2018 at 10:54:25AM +0100, Laszlo Ersek wrote:
> (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".

On a virtual machine it is very simple to switch the firmware (unlike on
physical machines), which I think is the main reason ovmf+csm never
really took off.

> (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.

IIRC there are still some corner cases which are not working and nobody
wants put any effort into fixing them.  S3 suspend comes to mind.

I'm not even sure it still works.  It builds, yes, my jenkins instance
does that.  But there is no testing beyond that, and I doubt that
someone else does regular ovmf+csm regression testing.  So the chances
that any runtime breakage goes unnoticed are pretty high ...

> (4) I also think an open source CSM implementation should exist, just so
> people can study it and experiment with it.

It'll not be deleted from git, so it'll be there even when removed from
master branch.

> In short, I think the community would benefit if someone continued to
> maintain the CSM infrastructure in edk2,

But what is the point in keeping the infrastructure if even physical
hardware starts to drop csm support?

So, I'd go with option (1).

cheers,
  Gerd