On Fri, Apr 05, 2019 at 09:19:48AM +0200, Michal Privoznik wrote:
If a management application wants to use firmware auto selection
feature it can't currently know if the libvirtd it's talking to
support is or not. Moreover, it doesn't know which values that
are accepted for the @firmware attribute of <os/> when parsing
will allow successful start of the domain later, i.e. if the mgmt
application wants to use 'bios' whether there exists a FW
descriptor in the system that describes bios.
This commit then adds 'firmware' enum to <os/> element in
<domainCapabilities/> XML like this:
<enum name='firmware'>
<value>bios</value>
<value>efi</value>
</enum>
We can see both 'bios' and 'efi' listed which means that there
are descriptors for both found in the system (matched with the
machine type and architecture reported in the domain capabilities
earlier and not shown here).
I wonder if we should also have a enum for the "secure" attribute
of <loader> to deal with SecureBoot
<enum name='secure'>
<value>yes</value>
<value>no</value>
</enum>
Always report "no", only report "yes" if there is at least one
firmware file we see that can do SecureBoot.
Yes, in theory that is a matrix against the firmware attribute
value, but we have many such dependancies between attributes
and it is not practical to fully express all valid combinations
in the capabilities, so taking the simple approach is valid
IMHO.
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 :|