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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
