On Thu, Mar 08, 2018 at 09:47:27PM +0100, Laszlo Ersek wrote:
On 03/08/18 16:47, Daniel P. Berrangé wrote:
> On Thu, Mar 08, 2018 at 12:10:30PM +0100, Laszlo Ersek wrote:
>> I suggest (or agree) that the property list be composed of free-form
>> name=value pairs (at least conceptually). I understand Gerd is proposing
>> a QAPI schema for this, so maybe do { property_name : "foo",
>> property_value : "bar" }, or similar. The registry of properties
(names,
>> possible values, meanings) should be kept separate (although possibly
>> still under QEMU).
>>
>> For OVMF (x86), I guess the initial set of properties should come from
>> the "-D FOO[=BAR]" build flags that OVMF currently supports. (The
list
>> might grow or change incompatibly over time, so this is just a raw
>> starter idea.)
>
> I really don't want to see us using firmware implementation specific
> property names in these files. It means libvirt will require knowledge
> of what each different firmware's property names mean.
>
> We need to have some core standardized set of property names that can
> be provided by any firmware implementation using the same terminology.
>
> If we want to /also/ provide some extra firmeware-specific property
> names that would be ok for informative purposes, but when lbivirt is
> picking which firmware file to use, it would only ever look at the
> standardized property names/values.
This is a reasonable requirement from the libvirt side.
Unfortunately (or not), it requires someone (or a tight group of people)
to collect the features of all virtual firmwares in existence, and
extract a common set of properties that maps back to each firmware one
way or another. This is not unusual (basically this is how all standards
bodies work that intend to codify existing practice), it just needs a
bunch of work and coordination. We'll have to maintain a registry.
Personally I can't comment on anything else than OVMF and the ArmVirt
firmwares.
I don't think it is actually a big problem. Today there is a very small
set of features we'll care about when selecting between firmware files.
For most architectures/firmwares, I expect there will just be a single
firmware image, tagged with architecture name, and possibly machine
type.
I think EFI will be the only case we have to start off with, where we
need to define a few extra standard features (for the SMM + secureboot
essentially). We can just iterate on this as more use cases / features
come to light.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|