Re: [Qemu-devel] [PATCH 10/14] tests: acpi: ignore SMBIOS tests when UEFI firmware is used

[Igor Mammedov <imammedo@redhat.com>]

On Wed, 16 Jan 2019 17:17:23 +0100
Laszlo Ersek <lersek@redhat.com> wrote:

> On 01/16/19 13:20, Igor Mammedov wrote:
> > On Wed, 16 Jan 2019 12:09:03 +0100
> > Laszlo Ersek <lersek@redhat.com> wrote:  
> >> On 01/16/19 12:07, Laszlo Ersek wrote:  
> 
> >>> In particular, for this approach, we don't even need gnu-efi. (Because,
> >>> personally, I would strongly prefer to write the UEFI application with
> >>> the edk2 framework.) For a while now, edk2 has supported "multiple
> >>> workspaces":
> >>>
> >>> https://github.com/tianocore/tianocore.github.io/wiki/Multiple_Workspace
> >>>
> >>> and as a result, it is possible to build the necessary UEFI app from:
> >>> - an edk2 checkout that the maintainer has "somewhere" on their disk,
> >>> - and the UEFI app source code that is contained in a QEMU checkout that
> >>> the maintainer has "somewhere else" on their disk.
> >>>
> >>> This approach allows the UEFI app source to live in the QEMU tree, and
> >>> the affected maintainer(s) would be personally responsible for setting
> >>> up their edk2 clones, and compilers. (The edk2 clone could even be a
> >>> submodule of QEMU, for example at roms/edk2.) For example,
> >>> "roms/Makefile" already calls an external EFIROM utility (also from
> >>> edk2) in order to build the combined iPXE option ROMs.
> >>>
> >>> And yes, we could turn the UEFI binaries into bootable ISO images at once.
> >>>
> >>> I'll try to post some patches soon (or not so soon). I think the app's
> >>> source code, and the edk2 submodule, should live under roms/, and the
> >>> bootable images should live under pc-bios/.
> >>>
> >>> (In fact we could use this opportunity to build & bundle OVMF itself...
> >>> not sure if that's in scope for now. Gerd, what's your take?)    
> 
> >> Oh, I should add: the UEFI app in question could be built without
> >> pulling in any OpenSSL bits; OVMF itself can't be built like that (it
> >> now has a hard dependency on OpenSSL). This might matter from a
> >> licensing/bundling perspective.  
> 
> > That's why I've suggested non EDK2 variant, as we don't need very much
> > from it and its license looks BDS like and it's very simple to build
> > pretty much for everyone.
> > Dealing with EDK2 to rebuild EFI is rather daunting prospect
> > (at least from my point of view so I'd try to avoid it if possible)  
> 
> Writing the app against edk2 is a lot simpler for me, and I have working
> experience with cross-compiling edk2 stuff from x86_64 to aarch64 as well.
> 
> OTOH I have zero experience with gnu-efi, especially when it comes to
> cross-compilation. System-level gnu-efi packages don't offer cross-built
> binaries anyway, so we can't get around a git submodule -- whether it's
> gnu-efi or edk2, we have to build from source.
> 
> And once we have a git submodule, I can put all the build commands in a
> simple shell script.
> 
> Regarding OpenSSL, the edk2 metafiles for the EFI app will make it
> evident that OpenSSL is not used. OpenSSL is anyway a git submodule of
> edk2, so if *that* submodule is not inited -- which you can verify --,
> then any OpenSSL references would fail to build. The resultant UEFI
> binary will be covered by the 2-clause BSDL (from core edk2) and
> whatever license we choose for the UEFI app itself (could be BSDL, could
> be GPL, as you prefer).
> 
> Obviously I'm willing to take on maintenance for the EFI app and the
> build script, if that works for you.
That works for me too, it would be better if anyone would be able to do
rebuild as well (i.e. some in tree magic script/make target that would
do rebuild when it's executed and ask for necessary deps if something
is missing)

> I understand the point of gnu-efi, but it's just unbearably limiting,
> relative to the goodies in edk2.
The project I've pointed out is gnu-efi less (it borrowed some linking magic
and some protocol definitions from gnu-efi), so it's even more limited
but we do not need even most of what it provides. So I was thinking that
would benefit you and a random contributor as well.


> Thanks,
> Laszlo