From: Laszlo Ersek <lersek@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Kashyap Chamarthy <kchamart@redhat.com>,
qemu-devel@nongnu.org, libvir-list@redhat.com, kraxel@redhat.com,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [Qemu-devel] [RFC] Defining firmware (OVMF, et al) metadata format & file
Date: Thu, 8 Mar 2018 21:47:27 +0100 [thread overview]
Message-ID: <c455f46b-dc25-fe7e-acc8-140f4a703e94@redhat.com> (raw)
In-Reply-To: <20180308154730.GZ4718@redhat.com>
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.
Thanks,
Laszlo
next prev parent reply other threads:[~2018-03-08 20:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-07 14:49 [Qemu-devel] [RFC] Defining firmware (OVMF, et al) metadata format & file Kashyap Chamarthy
2018-03-07 15:18 ` Daniel P. Berrangé
2018-03-08 7:52 ` Gerd Hoffmann
2018-03-08 10:17 ` Daniel P. Berrangé
2018-04-06 17:28 ` Laszlo Ersek
2018-04-06 18:10 ` Eric Blake
2018-04-06 18:21 ` Laszlo Ersek
2018-04-09 9:02 ` Kashyap Chamarthy
2018-04-09 15:32 ` Laszlo Ersek
2018-03-09 10:02 ` Kashyap Chamarthy
2018-03-08 7:45 ` Gerd Hoffmann
2018-03-08 10:16 ` Daniel P. Berrangé
2018-03-08 11:10 ` Laszlo Ersek
2018-03-08 15:47 ` Daniel P. Berrangé
2018-03-08 20:47 ` Laszlo Ersek [this message]
2018-03-09 11:27 ` Kashyap Chamarthy
2018-03-09 15:09 ` Laszlo Ersek
2018-03-12 11:17 ` Daniel P. Berrangé
2018-03-09 14:27 ` Gerd Hoffmann
2018-03-09 15:18 ` Laszlo Ersek
2018-03-12 11:13 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c455f46b-dc25-fe7e-acc8-140f4a703e94@redhat.com \
--to=lersek@redhat.com \
--cc=ard.biesheuvel@linaro.org \
--cc=berrange@redhat.com \
--cc=kchamart@redhat.com \
--cc=kraxel@redhat.com \
--cc=libvir-list@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).