Re: Drop CSM support in OvmfPkg?

[Laszlo Ersek <lersek@redhat.com>]

Hi All,

On 01/23/19 04:43, Ni, Ray wrote:
>> -----Original Message-----
>> From: David Woodhouse <dwmw2@infradead.org>
>> Sent: Wednesday, January 23, 2019 12:23 AM
>> To: Ni, Ray <ray.ni@intel.com>; Gerd Hoffmann <kraxel@redhat.com>;
>> Laszlo Ersek <lersek@redhat.com>; Richardson, Brian
>> <brian.richardson@intel.com>
>> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; edk2-devel@lists.01.org;
>> Kevin O'Connor <kevin@koconnor.net>; Anthony Perard
>> <anthony.perard@citrix.com>
>> Subject: Re: Drop CSM support in OvmfPkg?
>>
>> On Tue, 2019-01-22 at 16:13 +0000, Ni, Ray wrote:
>>> David,
>>> I'd like to re-start the discussion.
>>> Could you please kindly explain the background/reason of adding CSM
>>> support in OVMF?
>>> Maybe knowing the reason can help to make further decisions of
>>> whether to
>>> A. keep it outside OvmfPkg
>>> B. keep it inside OvmfPkg
>>> C. maybe have a chance to just remove the CSM support after
>>> revisiting
>>
>>
>> The idea was to make it simple to have a single firmware image for
>> virtual machines which would support both UEFI and Legacy boot for
>> guests simultaneously.
>>
>> In libvirt there has been an alternative approach, where the BIOS image
>> is switched between OVMF and SeaBIOS according to the configuration of
>> the guest VM.
>>
>> That's fine for libvirt, but in situations where VM hosting is provided
>> as a service, it becomes quite painful to manage the 'UEFI' vs.
>> 'Legacy' flags on guest images and then switch firmware images
>> accordingly. A one-size-fits-all BIOS using OVMF+CSM is very much
>> preferable.
> 
> David,
> Thanks for sharing. I now understand that you do have a need of
> CSM + UEFI OVMF image.
> A very straightforward idea is to move all COM components you needed
> into OvmfPkg. But Laszlo as the OvmfPkg owner may disagree with this.
> So maybe you could set up another (github) repo and clone all the CSM components
> there.
> EDKII build tool supports to build firmware from multiple repos.
> That's how we can have edk2-platforms and to-be-created edk2-app.
> In practical, you could create a new csm repo.
> Laszlo/Gerd who don't care about CSM can just build OVMF image from edk2 repo.
> You can build the OVMF image from edk2 and csm repo.
> 
> We can have a call if you are ok. I can explain how that can work in details.

I'm fine if we move the generic CSM components into OvmfPkg, however I'm
going to ask David to assume reviewer responsibilities for them.

Given the current format of "Maintainers.txt", we couldn't spell out the
exact pathnames of the CSM components, so we'd add a line like

R: David Woodhouse <dwmw2@infradead.org>

under OvmfPkg. There is "prior art" for this pattern, see:

R: Anthony Perard <anthony.perard@citrix.com>
R: Julien Grall <julien.grall@linaro.org>

Because Anthony and Julien are the authority on Xen-related code under
OvmfPkg. (See commit 337fe6a06eda, "Maintainers.txt: add Xen reviewers
to OvmfPkg", 2017-09-26.)


If we keep CSM support in OvmfPkg in any form at all, then I would
prefer holding all the related stuff in the core edk2 repository (with
the above Reviewership), over requiring people to deal with multiple
repositories. I agree (from experience) that PACKAGES_PATH / multiple
workspaces work fine, but in this case I think keeping one shared
history is an advantage.

Thanks,
Laszlo