[libvirt] [qemu RFC] qapi: add "firmware.json"

[Laszlo Ersek]

On 04/09/18 10:19, Gerd Hoffmann wrote:
>>> +{ 'enum' : 'SystemFirmwareType',
>>> +  'data' : [ 'bios', 'slof', 'uboot', 'uefi' ] }
>>
>> The naming here is quite a bad mixture between firmware interface
>> ('bios', 'uefi') and firmware implementations ('slof', 'uboot'). There
>> could be other implementations of BIOS or UEFI than SeaBIOS and EDK2 ...
>> so I'd suggest to rather name them 'seabios' and 'edk2' here instead.
> 
> uboot for example implements uefi unterfaces too (dunno how complete,
> but reportly recent versions can run uefi shell and grub just fine).

Indeed: when I was struggling with this enum type and tried to look for
more firmware types to add, my googling turned up the "UEFI on Top of
U-Boot" whitepaper, from Alex and Andreas :)

Again, this reaches to the root of the problem: when a user creates a
new domain, using high-level tools, they just want to tick "UEFI". (Dan
has emphasized this to me several times, so I think I get the idea by
now, if not the full environment.) We cannot ask the user, "please be
more specific, do you want UEFI from edk2, or UEFI on top of U-Boot?"

Instead, each of those firmware images will have to come with a JSON
document that states "uefi" in SystemFirmware.type, and the host admin
will be responsible for establishing a priority order between them.
Then, when the user asks for "UEFI" (and no more details), they'll get
(compatibly with the target architecture) whichever firmware the host
admin marked as "higher priority".

(Please be aware that with this argument, I'm trying to put myself into
Dan's shoes. It doesn't come *naturally* to me; in fact I'm viscerally
screaming inside at this amount of "fuzz". Personally I'd say, "I can
give you what you *say*, not what you *mean*, so *say* what you mean".
Apparently, that cannot work here, because what users mean is "UEFI" and
nothing more. I have to accept that.)

Thanks
Laszlo