From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Eduardo Habkost" <eduardo@habkost.net>,
"Richard Henderson" <richard.henderson@linaro.org>,
qemu-devel@nongnu.org, "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Dov Murik" <dovmurik@linux.ibm.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH 2/2] hw/i386: support loading OVMF using -bios too
Date: Fri, 14 Jan 2022 13:07:08 -0500 [thread overview]
Message-ID: <20220114125946-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20220113165511.46098-3-berrange@redhat.com>
On Thu, Jan 13, 2022 at 04:55:11PM +0000, Daniel P. Berrangé wrote:
> Traditionally the OVMF firmware has been loaded using the pflash
> mechanism. This is because it is usually provided as a pair of
> files, one read-only containing the code and one writable to
> provided persistence of non-volatile firmware variables.
>
> The AMD SEV build of EDK2, however, is provided as a single
> file that contains only the code. This is intended to be used
> read-only and explicitly does not provide any ability for
> persistance of non-volatile firmware variables. While it is
> possible to configure this with the pflash mechanism, by only
> providing one of the 2 pflash blobs, conceptually it is a
> little strange to use pflash if there won't be any persistent
> data.
>
> A stateless OVMF build can be loaded with -bios, however, QEMU
> does not currently initialize SEV in that scenario. This patch
> introduces the call needed for SEV initialization of the
> firmware.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
> hw/i386/x86.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/hw/i386/x86.c b/hw/i386/x86.c
> index b84840a1bb..c79d84936f 100644
> --- a/hw/i386/x86.c
> +++ b/hw/i386/x86.c
> @@ -45,6 +45,7 @@
> #include "target/i386/cpu.h"
> #include "hw/i386/topology.h"
> #include "hw/i386/fw_cfg.h"
> +#include "hw/i386/pc.h"
> #include "hw/intc/i8259.h"
> #include "hw/rtc/mc146818rtc.h"
> #include "target/i386/sev.h"
This builds fine because there's a stub in pc_sysfw_ovmf-stubs.c
The unfortunate thing about this however is that it's too easy to pull
in a PC dependency, and people building with CONFIG_PC will not notice
until it breaks for others.
Is it time we split pc.h further and had pc_sysfw_ovmf.h ?
> @@ -1157,6 +1158,10 @@ void x86_bios_rom_init(MachineState *ms, const char *default_firmware,
> memory_region_add_subregion(rom_memory,
> (uint32_t)(-bios_size),
> bios);
> +
> + pc_system_ovmf_initialize_sev(
> + rom_ptr((uint32_t)-bios_size, bios_size),
> + bios_size);
Just curious about the formatting here:
pc_system_ovmf_initialize_sev(rom_ptr((uint32_t)-bios_size, bios_size),
bios_size);
would be prettier ...
> }
>
> bool x86_machine_is_smm_enabled(const X86MachineState *x86ms)
> --
> 2.33.1
next prev parent reply other threads:[~2022-01-14 18:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-13 16:55 [PATCH 0/2] Improved support for AMD SEV firmware loading Daniel P. Berrangé
2022-01-13 16:55 ` [PATCH 1/2] hw/i386: refactor logic for setting up SEV firmware Daniel P. Berrangé
2022-01-13 16:55 ` [PATCH 2/2] hw/i386: support loading OVMF using -bios too Daniel P. Berrangé
2022-01-14 18:07 ` Michael S. Tsirkin [this message]
2022-01-16 21:05 ` Philippe Mathieu-Daudé via
2022-01-17 8:53 ` Michael S. Tsirkin
2022-01-17 7:34 ` [PATCH 0/2] Improved support for AMD SEV firmware loading Dov Murik
2022-01-17 11:56 ` Daniel P. Berrangé
2022-01-17 12:12 ` Brijesh Singh
2022-01-20 10:15 ` 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=20220114125946-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=dovmurik@linux.ibm.com \
--cc=eduardo@habkost.net \
--cc=f4bug@amsat.org \
--cc=kraxel@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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.