All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>,
	qemu-devel@nongnu.org, libvir-list@redhat.com
Cc: "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>,
	Gerd Hoffmann <kraxel@redhat.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>
Subject: Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"
Date: Mon, 9 Apr 2018 10:08:32 +0200	[thread overview]
Message-ID: <979bd720-cdb3-6468-1fbd-e8ec1c6c6c8d@redhat.com> (raw)
In-Reply-To: <20180407000117.25640-1-lersek@redhat.com>

On 07.04.2018 02:01, Laszlo Ersek wrote:
> Add a schema that describes the properties of virtual machine firmware.
[...]
> +##
> +# @SystemFirmware:
> +#
> +# Describes a system firmware binary and any NVRAM slots that it requires.
> +#
> +# @executable: Identifies the platform firmware executable.
> +#
> +# @type: The type by which the system firmware is commonly known. This is the
> +#        main search key by which management software looks up a system
> +#        firmware image for a new domain.
> +#
> +# @targets: a non-empty list of target architectures that are capable of
> +#           executing the system firmware
> +#
> +# @sysfw-map: the mapping requirements of the system firmware binary
> +#
> +# @nvram-slots: A list of NVRAM slots that are required by the system firmware.
> +#               The @slot-id field must be unique across the list. Importantly,
> +#               if any @FirmwareAccess is @restricted-to-secure-context in
> +#               @sysfw-map or in any @nvram-map in @nvram-slots, then (a) the
> +#               virtual machine configuration is required to emulate the secure
> +#               code execution context (as defined for @targets), and (b) the
> +#               virtual machine configuration is required to actually restrict
> +#               the access in question to the secure execution context.
> +#
> +# @supports-uefi-secure-boot: Whether the system firmware implements the
> +#                             software interfaces for UEFI Secure Boot, as
> +#                             defined in the UEFI specification. If the field
> +#                             is missing, its assumed value is 'false'.
> +#
> +# @supports-amd-sev: Whether the system firmware supports running under AMD
> +#                    Secure Encrypted Virtualization, as specified in the AMD64
> +#                    Architecture Programmer's Manual. If the field is missing,
> +#                    its assumed value is 'false'.
> +#
> +# @supports-acpi-s3: Whether the system firmware supports S3 sleep (suspend to
> +#                    RAM), as defined in the ACPI specification. If the field
> +#                    is missing, its assumed value is 'false'.
> +#
> +# @supports-acpi-s4: Whether the system firmware supports S4 hibernation
> +#                    (suspend to disk), as defined in the ACPI specification.
> +#                    If the field is missing, its assumed value is 'false'.
> +#
> +# Since: 2.13
> +#
> +# Examples:
> +#
> +# {
> +#     "executable": {
> +#         "pathname": "/usr/share/seabios/bios-256k.bin",
> +#         "description": "SeaBIOS",
> +#         "tags": [
> +#             "CONFIG_ROM_SIZE=256"
> +#         ]
> +#     },
> +#     "type": "bios",
> +#     "targets": [
> +#         "i386",
> +#         "x86_64"
> +#     ],
> +#     "sysfw-map": {
> +#         "device": "memory",
> +#         "write": "denied"
> +#     },
> +#     "supports-acpi-s3": true,
> +#     "supports-acpi-s4": true
> +# }
> +#
> +# {
> +#     "executable": {
> +#         "pathname": "/usr/share/OVMF/OVMF_CODE.secboot.fd",
> +#         "description": "OVMF with Secure Boot and SMM-protected varstore",
> +#         "tags": [
> +#             "FD_SIZE_4MB",
> +#             "IA32X64",
> +#             "SECURE_BOOT_ENABLE",
> +#             "SMM_REQUIRE"
> +#         ]
> +#     },
> +#     "type": "uefi",
> +#     "targets": [
> +#         "x86_64"
> +#     ],
> +#     "sysfw-map": {
> +#         "device": "flash",
> +#         "write": "denied"
> +#     },
> +#     "nvram-slots": [
> +#         {
> +#             "slot-id": 1,
> +#             "nvram-map" : {
> +#                 "device": "flash",
> +#                 "write": "restricted-to-secure-context"
> +#             },
> +#             "templates": [
> +#                 {
> +#                     "pathname": "/usr/share/OVMF/OVMF_VARS.fd",
> +#                     "description": "empty varstore template"
> +#                 },
> +#                 {
> +#                     "pathname": "/usr/share/OVMF/OVMF_VARS.secboot.fd",
> +#                     "description": "varstore template with the Microsoft certificates enrolled for Secure Boot",
> +#                     "tags": [
> +#                         "mscerts"
> +#                     ]
> +#                 }
> +#             ]
> +#         }
> +#     ],
> +#     "supports-uefi-secure-boot": true,
> +#     "supports-amd-sev": true,
> +#     "supports-acpi-s3": true
> +# }
> +#
> +# {
> +#     "executable": {
> +#         "pathname": "/usr/share/AAVMF/AAVMF_CODE.fd",
> +#         "description": "ARM64 UEFI firmware",
> +#         "tags": [
> +#             "AARCH64"
> +#         ]
> +#     },
> +#     "type": "uefi",
> +#     "targets": [
> +#         "aarch64"
> +#     ],

Another thought: I think that "targets" field is not enough. You also
need to map firmware images to certain machines. For example, on
aarch64, the AAVMF firmware only works on the "virt" machine, but not on
"raspi2" (I guess). On ppc64, SLOF only works for "pseries", but not for
the other machines like "mac99" or "g3beige". And on x86_64, EDK2 only
works for "q35" and "pc-i440fx", but not for "isapc".

 Thomas

  parent reply	other threads:[~2018-04-09  8:08 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
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 [this message]
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=979bd720-cdb3-6468-1fbd-e8ec1c6c6c8d@redhat.com \
    --to=thuth@redhat.com \
    --cc=agraf@suse.de \
    --cc=ard.biesheuvel@linaro.org \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --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=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.