Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

[Laszlo Ersek]

On 04/10/18 11:55, Daniel P. Berrangé wrote:
> On Tue, Apr 10, 2018 at 11:51:31AM +0200, Gerd Hoffmann wrote:
>>>> Hmm, I'm wondering whenever it is useful to model things this way.  It's
>>>> not like you can actually configure things for -bios seabios.rom or
>>>> -kernel uboot.elf.  Only pflash allows to actually configure things, and
>>>> there are not that many useful combinations.  The code needs
>>>> Read+Execute.  Allowing Write could be useful in theory, to allow the
>>>> guest doing firmware updates.  But I think nobody actually does that, so
>>>> in practice it is fixed.  The varstore can have different permissions,
>>>> but it's only two useful combinations.  Either allow access
>>>> unconditionally, or allow access in secure contect (aka smm) only.
>>>
>>> (I hope I understand your point right:)
>>>
>>> I'm also fine if we simply define a fixed (but extensible) set of
>>> mapping methods, basically a new enum type, that simply tells libvirtd
>>> what this firmware *is*. IOW, directly reference a mapping method we
>>> know libvirt implements, rather than give vague hints.
>>>
>>> This could repurpose SystemFirmwareType, but it should become more
>>> detailed. I'm thinking like:
>>> - ovmf: split files without requiring SMM
>>> - ovmf_smm: split files with SMM requirement
>>> - seabios: exactly that
>>> - ... other things others suggest.
>>
>> I wouldn't name them by firmware, that is misleading.  Basically we have
>> three cases:
>>
>>   (1) single firmware image (seabios, OVMF.fd, ...).
>>   (2) split firmware image (OVMF_{CODE,VARS}.fd), where vars can be
>>       writable unconditinally.
>>   (3) split firmware image, where access to vars should be restricted
>>       to smm mode.
>>
>> (2) + (3) requires pflash.  (1) works with both pflash and -bios.
> 
> A big chunk of the data in the schema looks specific to the pflash
> case, but this is not expressed except in the docs. Most of the time
> with QAPI when we have data that is only relevant in certain types,
> we use a discriminated union to describe it. It feels like a unioon
> approach could be better suited to this

I used a discriminated union specifically for pflash options in RFCv0,
which I didn't post. I felt that it wasn't flexible enough. :)

Laszlo