On Thu, Mar 07, 2019 at 10:29:10AM +0100, Michal Privoznik wrote:
v2 of:
https://www.redhat.com/archives/libvir-list/2019-February/msg01503.html
As usual, you can find my patches at my github:
https://github.com/zippy2/libvirt/commits/firmware_v2
diff to v1:
- Hopefully all Lazlo's comment are worked in (fixing the logic that
chooses suitable firmware for secboot/SMM domains, commit message
adjustements, sanity check for parsed FW descriptions, etc.)
- Added more debug messages around FW selection code, i.e. it'll be
visible from the logs why given FS is not suitable (or that it is).
I've done a very quick review of the patches and the design and
overall implementation strategy looks good to me. A few misc
points
- We ought to expose the list of firmware types supported
in the domain capabilities, so mgmt apps can probe if
uefi is available
- What should we do about the 'nvram' config from /etc/libvirt/qemu.conf
We can't get rid of it for a while, since the new firmware configs
won't be widely supported by distros in forseeable future. In the
places which currently use the 'nvram' config though, should we
make sure we consult the firmware configs in prefereence to
resolve the var store ? Maybe your code is already doing this and
I missed the logic from the diffs.
- We support 'bios' and 'efi' right now, but QEMU also reoprts
'openfirmware' and 'uboot' as supported types. In practice
no config files probably exist for those yet, but if it is
easy to make the code support them we should try todo it to
get parity with the QEMU spec
I don't think any of these are blockers though - all would work
as followup patches I expect.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|