Re: Drop CSM support in OvmfPkg?

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On Wed, 23 Jan 2019 at 10:55, Laszlo Er

> > That's going to be a hard thing to keep from happening over time, as
> > this is valid C :(sek <lersek@redhat.com> wrote:
>
> 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.
>

I don't have an opinion on whether we should keep CSM or not in
OvmfPkg. But if we do, I agree we should just move all the pieces we
rely on and that are getting dropped into OvmfPkg/ proper, rather than
keeping them on the side somewhere.