On Fri, Sep 2, 2022 at 11:02 AM Gerd Hoffmann <kraxel@redhat.com> wrote:

> On Sat, Aug 27, 2022 at 02:02:00AM +0200, Théo wrote:
> > From: Théo Jehl <theojehl76@gmail.com>
> >
> > QemuOpenBoardPkg adds a MinPlatform port to Qemu x86_64
> > It can boots UEFI Linux and Windows, and works on PIIX4 and Q35
> > This board port provides a simple starting place for investigating edk2
> and
> > MinPlatform Arch.
> > Currently we implement up to stage 4 of the MinPlatform spec and can boot
> > Windows/Linux.
>
> That is a rather short description for a patch of this size.  It
> probably makes sense to break that down into smaller pieces and make a
> patch series out of it because you can describe the specific pieces much
> better then.
>
> I'm not familiar with MinPlatform, just skimmed the manual.  Can't
> comment much on those details.
>
> It seems the goal is to have a MinPlatform board which can easily be
> used to learn about and experiment with MinPlatform, is that correct?
>
Hi Gerd,

Yes, for now the goal is to have a MinPlatform board that is simple and
easy to use as a learning tool. However, in my opinion the future remains
unclear. I think we (as in EDK2) could benefit by moving OVMF itself to
MinPlatform, so some merging of QemuOpenBoardPkg and OvmfPkg (in the
future, of course) would be a cool idea. I think OVMF has grown a bit hairy
in a few places and has a bunch of logic that is already covered in
MinPlatform. I believe that we got something close enough to OVMF (of
course, while using some OvmfPkg modules and libraries) but drastically
simpler. I don't know if you share the same opinion; some feedback from you
OvmfPkg folks would be interesting.

At the very least, it will serve as a learning tool - it's a great example
of "How to create your own firmware", in a relatively straightforward and
blobless way. Maybe more valuable as a learning tool than an OVMF
replacement, but that of course is open for discussion. We've limited
ourselves to targeting "simple learning MinPlatform (and firmware
programming in general) tool" as writing a full replacement of OVMF would
be very much impossible in 3 months, as you're aware :)

>
> >
> Platform/Qemu/QemuOpenBoardPkg/Library/OpenQemuFwCfgLib/OpenQemuFwCfgLib.inf
>      |  23 +
> >  Platform/Qemu/QemuOpenBoardPkg/Include/Library/OpenQemuFwCfgLib.h
>             | 102 +++
> >
> Platform/Qemu/QemuOpenBoardPkg/Library/OpenQemuFwCfgLib/OpenQemuFwCfgLib.c
>        | 130 ++++
>
> Why duplicate that lib instead of just using the OvmfPkg version (which
> you do elsewhere)?
>
> >  Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Cpu.c
>            |  56 ++
> >  Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Memory.c
>             | 244 ++++++++
> >  Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Pci.c
>            |  59 ++
> >  Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Pcie.c
>             |  91 +++
> >  Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/PlatformInit.c
>             |  67 ++
>
> Note that OvmfPkg got a PlatformInitLib recently which you might be able
> to use to reduce code duplication (didn't check the code though and
> maybe MinPlatform init is different enough that this doesn't help much).
>
> Some context on these two libs:
OpenQemuFwCfgLib was created early on as a way to manage initial complexity
and as a way to get Théo to code a bit. I'm not too sure we'll want to keep
that library around.
PlatformInitPei was again created to manage complexity (and to implement
MinPlatform of course) - this ended up getting all the PEI platform
initialization code, instead of using OVMF's PlatformInitLib.

You'll notice that there's some overlap in functionality between QemuOBP
and OVMF. While it's not the most elegant solution from a "UEFI
super-duper-modular" POV, I think it was a better end product than getting
Théo to look at .dsc and .fdf files for 3 months; we actually went through
x86 PC platform initialization and I'm reasonably confident Théo not only
understands how x86 PC works, but that he could write it all on his own
again. We also got something with less historical baggage and that resulted
in cleaner, simpler code. It also doesn't support every bell and whistle in
QEMU and I'm willing to bet it straight up breaks if you go back enough in
QEMU versions; but again, at the current stage it's not a replacement for
full OVMF functionality, but rather the most common subset of it (no TDX,
no SEV, no CPU hotplug, restricts itself to relatively recent versions, SMM
and secure boot are not in this patch set but are in progress).

Thanks,
Pedro