[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 0/3] acceptance tests: Test firmware checkin
Re: [Qemu-devel] [RFC PATCH 0/3] acceptance tests: Test firmware checking debug console output
Sat, 29 Sep 2018 13:10:47 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
On 09/28/18 19:07, Philippe Mathieu-Daudé wrote:
> On 28/09/2018 12:51, Laszlo Ersek wrote:
>> Figuring out the options is complicated enough (for management tools
>> as well) that Daniel made us define a metadata schema for describing
>> firmware packages. Please see:
>> I'm not necessarily suggesting that Avocado be able to parse the
>> firmware descriptor metafiles that conform to this schema. I'm just
>> pointing out that the QEMU command line will depend on the exact build
>> of the firmware image under test. The pathname
>> "/usr/share/OVMF/OVMF_CODE.fd" and the URL
>> "https://snapshots.linaro.org/.../QEMU_EFI.img.gz" don't give us
>> enough information.
>> Therefore, if we want to keep the test case simple (= hard-wire the
>> command lines), then we'll have to refer to OVMF and ArmVirtQemu
>> images with precisely known build configs.
> To focus on QEMU here, I'd like to not have to build a know EDK2 config
> but rather use releases (or snapshots).
If you mean specific binary releases (released by some well-known
specific party), that should work; but they should be available to everyone.
If you mean source releases / snapshots, those don't provide enough
information. You can still build OVMF with and without -D SMM_REQUIRE,
for example, and the QEMU command line options will differ.
This is not much different from using a Linux guest kernel image for
testing. For example, you can build Linux without virtio drivers, and
then you can't use the resultant image for checking QEMU's virtio
devices. I.e., the guest build config is part of the equation.
> scripts/qemu.py should provide utilities to pack a flash image for
> further testing.
AIUI, upstream QEMU wouldn't like to bundle more binaries / depend on
more external projects.
Also, if you build OVMF with a feature that requires OpenSSL, then the
resultant binary (covered by the 2-clause BSD license and the OpenSSL
license) might not be suitable for bundling with QEMU.