| Message ID | 1547566866-129386-11-git-send-email-imammedo@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | tests: acpi: add UEFI (ARM) testing support | expand |
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? Thanks, Laszlo > > Signed-off-by: Igor Mammedov <imammedo@redhat.com> > --- > tests/bios-tables-test.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c > index d9efe59..a64d0c2 100644 > --- a/tests/bios-tables-test.c > +++ b/tests/bios-tables-test.c > @@ -562,8 +562,11 @@ static void test_acpi_one(const char *params, test_data *data) > } > } > > - test_smbios_entry_point(data); > - test_smbios_structs(data); > + /* TODO: make SMBIOS tests work with UEFI firmware */ > + if (!use_uefi) { > + test_smbios_entry_point(data); > + test_smbios_structs(data); > + } > > assert(!global_qtest); > qtest_quit(data->qts); >
On Tue, 15 Jan 2019 21:31:54 +0100 Laszlo Ersek <lersek@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 ? > Thanks, > Laszlo > > > > > Signed-off-by: Igor Mammedov <imammedo@redhat.com> > > --- > > tests/bios-tables-test.c | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c > > index d9efe59..a64d0c2 100644 > > --- a/tests/bios-tables-test.c > > +++ b/tests/bios-tables-test.c > > @@ -562,8 +562,11 @@ static void test_acpi_one(const char *params, test_data *data) > > } > > } > > > > - test_smbios_entry_point(data); > > - test_smbios_structs(data); > > + /* TODO: make SMBIOS tests work with UEFI firmware */ > > + if (!use_uefi) { > > + test_smbios_entry_point(data); > > + test_smbios_structs(data); > > + } > > > > assert(!global_qtest); > > qtest_quit(data->qts); > > > >
+Gerd On 01/16/19 11:32, Igor Mammedov wrote: > On Tue, 15 Jan 2019 21:31:54 +0100 > Laszlo Ersek <lersek@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?) Thanks, Laszlo
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 <lersek@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
Hi, > 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?) Well, there is still the idea to move over firmware submodules and prebuilt firmware blobs to a separate repo. Expermimental repo: https://git.kraxel.org/cgit/qemu-firmware/. Not touched for more than a year due to being busy with other stuff. Oh well ... (if someone feels like picking this up feel free to do so). I think adding edk2 as submodule below roms/ makes sense. Adding rules to roms/Makefile to build the blobs makes sense too. Not sure we want the binaries actually copied over to pc-bios/ and commited as the uefi firmware is pretty big ... Not sure what a good place for the uefi app would be. I'd tend to not use roms/, that is the place for firmware submodules. contrib/ or test/ maybe? cheers, Gerd
On Wed, 16 Jan 2019 12:09:03 +0100 Laszlo Ersek <lersek@redhat.com> 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 <lersek@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. 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
On Wed, 16 Jan 2019 12:52:17 +0100 Gerd Hoffmann <kraxel@redhat.com> wrote: > Hi, > > > 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?) > > Well, there is still the idea to move over firmware submodules and > prebuilt firmware blobs to a separate repo. Expermimental repo: > https://git.kraxel.org/cgit/qemu-firmware/. Not touched for more than a > year due to being busy with other stuff. Oh well ... > > (if someone feels like picking this up feel free to do so). > > I think adding edk2 as submodule below roms/ makes sense. Adding rules > to roms/Makefile to build the blobs makes sense too. Not sure we want > the binaries actually copied over to pc-bios/ and commited as the uefi > firmware is pretty big ... > > Not sure what a good place for the uefi app would be. I'd tend to not > use roms/, that is the place for firmware submodules. contrib/ or test/ > maybe? Could be tests/data/acpi in this case > > cheers, > Gerd >
On Wed, Jan 16, 2019 at 12:52:17PM +0100, Gerd Hoffmann wrote: > Hi, > > > 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?) > > Well, there is still the idea to move over firmware submodules and > prebuilt firmware blobs to a separate repo. What's the advantage of this? 99% of people want the specific firmware shipped with QEMU. Ony firmware developers might save a bit of disk space. Seems like a loss overall. > Expermimental repo: > https://git.kraxel.org/cgit/qemu-firmware/. Not touched for more than a > year due to being busy with other stuff. Oh well ... > > (if someone feels like picking this up feel free to do so). > > I think adding edk2 as submodule below roms/ makes sense. Adding rules > to roms/Makefile to build the blobs makes sense too. Not sure we want > the binaries actually copied over to pc-bios/ and commited as the uefi > firmware is pretty big ... > > Not sure what a good place for the uefi app would be. I'd tend to not > use roms/, that is the place for firmware submodules. contrib/ or test/ > maybe? > > cheers, > Gerd
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. I understand the point of gnu-efi, but it's just unbearably limiting, relative to the goodies in edk2. Thanks, Laszlo
On 01/16/19 13:31, Igor Mammedov wrote: > On Wed, 16 Jan 2019 12:52:17 +0100 > Gerd Hoffmann <kraxel@redhat.com> wrote: > >> Hi, >> >>> 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?) >> >> Well, there is still the idea to move over firmware submodules and >> prebuilt firmware blobs to a separate repo. Expermimental repo: >> https://git.kraxel.org/cgit/qemu-firmware/. Not touched for more than a >> year due to being busy with other stuff. Oh well ... >> >> (if someone feels like picking this up feel free to do so). >> >> I think adding edk2 as submodule below roms/ makes sense. Adding rules >> to roms/Makefile to build the blobs makes sense too. Not sure we want >> the binaries actually copied over to pc-bios/ and commited as the uefi >> firmware is pretty big ... >> >> Not sure what a good place for the uefi app would be. I'd tend to not >> use roms/, that is the place for firmware submodules. I figured the source code for the UEFI app would fit due to the script "configure-seabios.sh" and some actual config files being there already. But, I'm happy to follow directions. :) >> contrib/ or test/ maybe? > Could be tests/data/acpi in this case If "tests/data/acpi" is appropriate for source code, that works for me. We already have "rebuild-expected-aml.sh" there, so I guess another build script and the UEFI app source code would fit there too. It would be nice if I could get around submitting some patches this week. Sigh. :/ Thanks, Laszlo
On Wed, 16 Jan 2019 17:22:31 +0100 Laszlo Ersek <lersek@redhat.com> wrote: > On 01/16/19 13:31, Igor Mammedov wrote: > > On Wed, 16 Jan 2019 12:52:17 +0100 > > Gerd Hoffmann <kraxel@redhat.com> wrote: > > > >> Hi, > >> > >>> 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?) > >> > >> Well, there is still the idea to move over firmware submodules and > >> prebuilt firmware blobs to a separate repo. Expermimental repo: > >> https://git.kraxel.org/cgit/qemu-firmware/. Not touched for more than a > >> year due to being busy with other stuff. Oh well ... > >> > >> (if someone feels like picking this up feel free to do so). > >> > >> I think adding edk2 as submodule below roms/ makes sense. Adding rules > >> to roms/Makefile to build the blobs makes sense too. Not sure we want > >> the binaries actually copied over to pc-bios/ and commited as the uefi > >> firmware is pretty big ... > >> > >> Not sure what a good place for the uefi app would be. I'd tend to not > >> use roms/, that is the place for firmware submodules. > > I figured the source code for the UEFI app would fit due to the script > "configure-seabios.sh" and some actual config files being there already. > But, I'm happy to follow directions. :) > > >> contrib/ or test/ maybe? > > > Could be tests/data/acpi in this case > > If "tests/data/acpi" is appropriate for source code, that works for me. > We already have "rebuild-expected-aml.sh" there, so I guess another > build script and the UEFI app source code would fit there too. I suggested tests/data/acpi for binary EFI app blobs For EFI app source maybe just 'tests' or sub-directory there and make 'make check-efi-app' build EFI app (doing all needed magic and asking for things that missing) if source is newer than blobs. > > It would be nice if I could get around submitting some patches this > week. Sigh. :/ > > Thanks, > Laszlo >
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
On 01/17/19 16:11, Igor Mammedov wrote: > On Wed, 16 Jan 2019 17:22:31 +0100 > Laszlo Ersek <lersek@redhat.com> wrote: > >> On 01/16/19 13:31, Igor Mammedov wrote: >>> On Wed, 16 Jan 2019 12:52:17 +0100 >>> Gerd Hoffmann <kraxel@redhat.com> wrote: >>> >>>> Hi, >>>> >>>>> 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?) >>>> >>>> Well, there is still the idea to move over firmware submodules and >>>> prebuilt firmware blobs to a separate repo. Expermimental repo: >>>> https://git.kraxel.org/cgit/qemu-firmware/. Not touched for more than a >>>> year due to being busy with other stuff. Oh well ... >>>> >>>> (if someone feels like picking this up feel free to do so). >>>> >>>> I think adding edk2 as submodule below roms/ makes sense. Adding rules >>>> to roms/Makefile to build the blobs makes sense too. Not sure we want >>>> the binaries actually copied over to pc-bios/ and commited as the uefi >>>> firmware is pretty big ... >>>> >>>> Not sure what a good place for the uefi app would be. I'd tend to not >>>> use roms/, that is the place for firmware submodules. >> >> I figured the source code for the UEFI app would fit due to the script >> "configure-seabios.sh" and some actual config files being there already. >> But, I'm happy to follow directions. :) >> >>>> contrib/ or test/ maybe? >> >>> Could be tests/data/acpi in this case >> >> If "tests/data/acpi" is appropriate for source code, that works for me. >> We already have "rebuild-expected-aml.sh" there, so I guess another >> build script and the UEFI app source code would fit there too. > I suggested tests/data/acpi for binary EFI app blobs > For EFI app source maybe just 'tests' or sub-directory there and make > 'make check-efi-app' build EFI app (doing all needed magic and asking for things that missing) > if source is newer than blobs. I've been busy all day hacking and staying away from email, so when you see that my patches didn't follow this closely in the end, please know that I didn't deliberately ignore your point -- I'm just getting to it now. Let's continue the discussion under [qemu-devel] [PATCH 0/5] add the BiosTablesTest UEFI app, build it with the new roms/edk2 submodule Thanks! Laszlo > >> >> It would be nice if I could get around submitting some patches this >> week. Sigh. :/ >> >> Thanks, >> Laszlo >> >
diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c index d9efe59..a64d0c2 100644 --- a/tests/bios-tables-test.c +++ b/tests/bios-tables-test.c @@ -562,8 +562,11 @@ static void test_acpi_one(const char *params, test_data *data) } } - test_smbios_entry_point(data); - test_smbios_structs(data); + /* TODO: make SMBIOS tests work with UEFI firmware */ + if (!use_uefi) { + test_smbios_entry_point(data); + test_smbios_structs(data); + } assert(!global_qtest); qtest_quit(data->qts);
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. Signed-off-by: Igor Mammedov <imammedo@redhat.com> --- tests/bios-tables-test.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)