Re: [libvirt] [qemu RFC v2] qapi: add "firmware.json"
On 04/20/18 10:47, Paolo Bonzini wrote:
On 20/04/2018 03:03, David Gibson wrote:
>> This also implies I shouldn't add "openbios" separately, which was
>> suggested earlier by Gerd -- according to
>> <https://en.wikipedia.org/wiki/OpenBIOS>;, OpenBIOS is another
>> implementation of OFW.
>
> Right. Although I think OpenBIOS and SLOF support a disjoint set of
> machines. Openhackware which is (was?) used on some machines is yet
> another (very partial) openfirmware implementation.
We can:
1a) replace the architecture field with an ABI field (seems wrong to me)
1b) add an "ABI" field (containing e.g. prep, spapr, etc.) to complement
the architecture field
2) we include directly a glob pattern for the QEMU machine types (also
seems wrong).
Using globs in machine types was what Gerd and Daniel agreed upon, and I
was planning to do for v3. :(
3) just like we effectively moved the guest ABI to the features
field,
No, we didn't -- while it's true that a single firmware image can
provide multiple guest ABIs, the implementation quality of those guest
ABIs is not identical, and there is a preference order between them. The
latest idea was to keep the @type field, but turn it into an ordered
list of enum constants. Whichever constant is near the top is the more
preferred ABI, and mgmt tools, when looking for "the" type of the
firware, would consider the topmost (first) element.
we split the features into host-features and guest-features, and the
host ABI (prep, spapr, etc.; but also OVMF's SMM requirement fits here
for example) moves into host-features. Again, just like 1a/1b, this can
be replace or complement the architecture field, and I think I'd prefer
the latter
I'd prefer if we could mostly stick with the structure of the schema as
seen in RFCv2 -- all the feedback until now implies that's possible,
with minor tweaks. Let me post an RFCv3 soon, so that we have a more
up-to-date basis for the discussion. (I've been waiting for some of the
architecture (emulation target) technicalities to clear up, but I guess
I had better postpone that now, because I see the discussion diverging.)
Thanks!
Laszlo