[libvirt] [PATCH 0/5] qemu: Use FW descriptors to report FW image paths

[Cole Robinson]

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 at 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