[libvirt] [PATCH v1 4/4] domain capabilities: Expose firmware auto selection feature

Michal Privoznik mprivozn at redhat.com
Fri Apr 5 08:44:44 UTC 2019


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




More information about the libvir-list mailing list