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 <ler...@redhat.com> 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. > > 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. Thanks, Laszlo