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