On 4/5/19 10:31 AM, Daniel P. Berrangé wrote:
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.
Makes sense, I'll put it on my TODO list for v2. Thanks, Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
