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@xxxxxxxxxx>
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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
