On 8/5/19 12:14 PM, Michal Privoznik wrote:
It feels a bit odd to report a built in list of FW images when we have FW descriptor files. Especially, when some weird architectures are concerned. For instance, OVMF_CODE.fd is reported even for non-x86_64/non-i386 arches, like ppc. But if FW descriptor files are taken into the picture then no OVMF_CODE.fd is ever reported.
One can argue, that these patches are not necessary, because the whole point of FW descriptor files is that users do not have to bother with paths to FW images. And that is true. However, the whole ecosystem of FW descriptor files allows sys admins and regular users to write their own FW descriptor files and thus reporting what paths libvirt found might come handy when writing those descriptors.
Michal Prívozník (5): virfirmware: Expose and define autoptr for virFirmwareFree qemu_firmware: Document qemuFirmwareGetSupported qemu_firmware: Extend qemuFirmwareGetSupported to return FW paths qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() qemu: Use FW descriptors to report FW image paths
src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 19 +++++++-- src/qemu/qemu_firmware.c | 81 +++++++++++++++++++++++++++++++++++- src/qemu/qemu_firmware.h | 5 ++- src/util/virfirmware.c | 2 +- src/util/virfirmware.h | 5 +++ tests/qemufirmwaretest.c | 78 ++++++++++++++++++++++++++++++---- 7 files changed, 177 insertions(+), 14 deletions(-)
Reviewed-by: Cole Robinson <crobinso@redhat.com> One problem with the output though, but I think it can be fixed as a follow on. $ sudo ./tools/virsh domcapabilities --machine q35 ... <loader supported='yes'> <value>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</value> <value>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</value> <value>/usr/share/edk2/ovmf/OVMF_CODE.fd</value> <enum name='type'> <value>rom</value> <value>pflash</value> </enum> <enum name='readonly'> <value>yes</value> <value>no</value> </enum> <enum name='secure'> <value>yes</value> <value>no</value> </enum> </loader> Notice the double secboot listing. This is on f31 with stock packages. Probably due to 50-edk2-ovmf-x64-sb.json and 40-edk2-ovmf-x64-sb-enrolled.json using the same firmware path. I guess dupes should be filtered out? Thanks, Cole