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