All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org, libvir-list@redhat.com,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Alexander Graf <agraf@suse.de>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	David Gibson <dgibson@redhat.com>, Eric Blake <eblake@redhat.com>,
	Gary Ching-Pang Lin <glin@suse.com>,
	Kashyap Chamarthy <kchamart@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Michael Roth <mdroth@linux.vnet.ibm.com>,
	Michal Privoznik <mprivozn@redhat.com>,
	Peter Krempa <pkrempa@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	David Gibson <david@gibson.dropbear.id.au>,
	Laurent Vivier <lvivier@redhat.com>,
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Subject: Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"
Date: Tue, 10 Apr 2018 11:32:47 +0200	[thread overview]
Message-ID: <9905fe6b-337d-d712-0851-472be3d55aca@redhat.com> (raw)
In-Reply-To: <713231ec-05c5-a135-65b1-bd26e08738f6@redhat.com>

On 10.04.2018 11:22, Laszlo Ersek wrote:
> On 04/10/18 09:33, Thomas Huth wrote:
[...]
>> Alternatively, what about providing some kind of "alias" or "nickname"
>> setting here, too? So the EDK2 builds would get
>> SystemFirmwareType="edk2" and "SystemFirmwareAlias="uefi" for example.
> 
> I hope I understand you right -- I think your suggestion ties in with my
> other email I just sent in this thread. So, we could tell libvirtd,
> "this firmware is of type 'UEFI', and you must use the 'ovmf_smm'
> mapping method to run it, with this file or that file as varstore template".
> 
> We could even describe the parameters for this or that mapping method
> structurally in the schema (in a discriminated union in QAPI JSON, or in
> an XSD choice element). For example, "ovmf" and "ovmf_smm" would both
> take "OvmfSplitFileOptions" -- a list of single varstore template files
> with feature enum contants attached  --, while "SeaBiosOptions" would be
> an empty structure.

Sorry, I've got no clue about ovmf_smm and the other things you've
mentioned here ;-)

> I feel the key question here is whether we are allowed to directly
> reference a mapping method we know libvirt implements. If we are, that
> makes things a lot clearer (and easier, I should hope).

Key question is maybe rather: Do you want to design / implement
something that is libvirt-only here, or rather something generic that
could also be used for other upper layer tools that do not use libvirt?
(... and looks like Daniel just had the same comment in another mail in
this thread ...)

 Thomas

  reply	other threads:[~2018-04-10  9:33 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-07  0:01 [Qemu-devel] [qemu RFC] qapi: add "firmware.json" Laszlo Ersek
2018-04-09  7:26 ` Thomas Huth
2018-04-09  8:19   ` Gerd Hoffmann
2018-04-09 16:50     ` Laszlo Ersek
2018-04-10  6:18       ` Gerd Hoffmann
2018-04-10  9:09         ` Laszlo Ersek
2018-04-10  7:33       ` Thomas Huth
2018-04-10  9:22         ` Laszlo Ersek
2018-04-10  9:32           ` Thomas Huth [this message]
2018-04-10 11:53             ` Laszlo Ersek
2018-04-10  9:09       ` Daniel P. Berrangé
2018-04-09 16:34   ` Laszlo Ersek
2018-04-10  5:59     ` Gerd Hoffmann
2018-04-10  9:07       ` Laszlo Ersek
2018-04-10  9:51         ` Gerd Hoffmann
2018-04-10  9:55           ` Daniel P. Berrangé
2018-04-10 12:04             ` Laszlo Ersek
2018-04-10  7:44     ` Thomas Huth
2018-04-10  8:57       ` Laszlo Ersek
2018-04-10  9:05     ` Daniel P. Berrangé
2018-04-10  9:19       ` Thomas Huth
2018-04-10 11:40       ` Laszlo Ersek
2018-04-09  8:08 ` Thomas Huth
2018-04-09 16:42   ` Laszlo Ersek
2018-04-10  6:27     ` Gerd Hoffmann
2018-04-10  9:16       ` Laszlo Ersek
2018-04-10  9:23         ` Daniel P. Berrangé
2018-04-10 10:09           ` Paolo Bonzini
2018-04-10 11:46             ` Laszlo Ersek
2018-04-10  9:26         ` Thomas Huth
2018-04-10 11:53           ` Laszlo Ersek
2018-04-10  9:34         ` Daniel P. Berrangé
2018-04-10 11:57           ` Laszlo Ersek
2018-04-09  8:26 ` Gerd Hoffmann
2018-04-09 16:53   ` Laszlo Ersek
2018-04-09  8:49 ` Daniel P. Berrangé
2018-04-09 17:57   ` Laszlo Ersek
2018-04-10  9:18     ` Daniel P. Berrangé
2018-04-10 11:27       ` Laszlo Ersek
2018-04-10 11:34         ` Daniel P. Berrangé
2018-04-10 11:44           ` Laszlo Ersek
2018-04-10 11:50             ` Daniel P. Berrangé
2018-04-10 11:48           ` Peter Maydell
2018-04-10 11:52             ` Daniel P. Berrangé
2018-04-10 10:20 ` Daniel P. Berrangé
2018-04-10 11:03   ` Daniel P. Berrangé
2018-04-10 11:37     ` Gerd Hoffmann
2018-04-10 12:12   ` Laszlo Ersek

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=9905fe6b-337d-d712-0851-472be3d55aca@redhat.com \
    --to=thuth@redhat.com \
    --cc=agraf@suse.de \
    --cc=ard.biesheuvel@linaro.org \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=dgibson@redhat.com \
    --cc=eblake@redhat.com \
    --cc=glin@suse.com \
    --cc=kchamart@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=mprivozn@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=pkrempa@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.