qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 10/14] tests: acpi: ignore SMBIOS tests when UEF


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH 10/14] tests: acpi: ignore SMBIOS tests when UEFI firmware is used
Date: Wed, 16 Jan 2019 13:20:46 +0100

On Wed, 16 Jan 2019 12:09:03 +0100
Laszlo Ersek <address@hidden> wrote:

> On 01/16/19 12:07, Laszlo Ersek wrote:
> > +Gerd
> > 
> > On 01/16/19 11:32, Igor Mammedov wrote:  
> >> On Tue, 15 Jan 2019 21:31:54 +0100
> >> Laszlo Ersek <address@hidden> wrote:
> >>  
> >>> On 01/15/19 16:41, Igor Mammedov wrote:  
> >>>> once FW provides a pointer to SMBIOS entry point like it does for
> >>>> RSDP it should be possible to enable this one the same way.    
> >>>
> >>> Good point, I didn't think of SMBIOS.
> >>>
> >>> We have the following options:
> >>>
> >>> (1) Use just one "test support" structure, and add more fields (such as
> >>> the SMBIOS entry point) to it, beyond the RSDP1.0/RSDP2.0. For this, we
> >>> should also introduce a "size" field to the table, so we don't have to
> >>> extend the table between firmware and QEMU in lock-step.
> >>>
> >>> (2) Use a different table (with a different GUID) for exposing the
> >>> SMBIOS entry point.
> >>>
> >>> On the firmware side, (1) would be more work now, but it would keep
> >>> things simpler (and better separated) in the future. (2) would be more
> >>> lazy ^W convenient now, but it would introduce more churn / possibly
> >>> some code duplication in the future.
> >>>
> >>> In QEMU, which one would you prefer?  
> >> I'd prefer #1 to minimize # of memory scans.
> >> However with size (i.e. implicit versioning) and who know what else in
> >> the future complexity grows up and dependency this approach causes
> >> between firmware and QEMU (I dislike special build instead of reusing
> >> shipped images).
> >>
> >> So I've dug a little bit into the history why we've chosen including
> >> structure into the firmware itself instead of writing EFI application
> >> as part of QEMU that would provide the same test structure but won't
> >> require special firmware build.
> >> If I sum it up, it was issue with distros are shipping (if they do it at 
> >> all)
> >> only a version that matches distro's architecture and a need for cross
> >> compiling EFI test app.
> >>
> >> Could we revisit EFI app approach (I'd prefer it over firwmare hack if it's
> >> possible)? We can try to avoid dependency on gnu-efi and cross compiling on
> >> regular builds and ship along with efi app source code several prebuild app
> >> binaries (boot disk images), that one would rebuild only when efi app
> >> is changed, and it could be done manually (the same like special fw build
> >> but contained withing QEMU). As for gnu-efi, is it possible to use striped
> >> down gnu-efi stubs to drop external library dependency, something along of
> >> lines https://github.com/tqh/efi-example ?  
> > 
> > If it is permissible to require the affected QEMU maintainers to
> > *manually* rebuild the UEFI binary on their workstations, whenever the
> > source code for the UEFI app changes, then the solution is a lot easier
> > indeed.
I expect EFI app won't change often based on how much we've changed similar
counterpart for BIOS version. So it probably ok, due to low load and we
won't have to waste resources on rebuilding static thing over and over again
on every qemu build (I'm horrified how much longer QEMU build would become
if we would have to pull in complex dependencies to build it).

> > 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)


> 
> Thanks,
> Laszlo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]