From: Ani Sinha <anisinha@redhat.com>
To: "Paolo Bonzini" <pbonzini@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Gerd Hoffmann" <kraxel@redhat.com>
Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org,
Ani Sinha <anisinha@redhat.com>
Subject: [PULL 2/3] hw/i386/ovmf: check if ovmf is supported before calling ovmf parsing code
Date: Wed, 5 Mar 2025 13:20:14 +0530 [thread overview]
Message-ID: <20250305075015.26892-3-anisinha@redhat.com> (raw)
In-Reply-To: <20250305075015.26892-1-anisinha@redhat.com>
Currently call to x86_firmware_configure() -> pc_system_parse_ovmf_flash()
happens only when SEV is enabled. Fortunately, X86_FW_OVMF is turned on
automatically when SEV is enabled and therefore, we never end up calling
pc_system_parse_ovmf_flash() when X86_FW_OVMF is turned off. In future,
it is possible that users call x86_firmware_configure() or
x86_firmware_reconfigure() without checking if SEV is enabled. Therefore,
x86_firmware_configure() or x86_firmware_reconfigure() need to check if
ovmf is supported before calling ovmf parsing code. Hence, this change
introduces an api ovmf_supported() that returns true wnen ovmf is enabled
and false otherwise. Ovmf parsing code is only called after checking if ovmf
is supported.
Message-ID: <20250228170434.317306-1-anisinha@redhat.com>
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
---
hw/i386/pc_sysfw.c | 18 +++++++++++-------
hw/i386/pc_sysfw_ovmf-stubs.c | 5 +++++
hw/i386/pc_sysfw_ovmf.c | 5 +++++
include/hw/i386/pc.h | 1 +
4 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index a9943d95c8..725d142606 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -278,17 +278,21 @@ static void x86_firmware_configure_sev(hwaddr gpa, void *ptr, int size)
void x86_firmware_configure(hwaddr gpa, void *ptr, int size)
{
- /*
- * OVMF places a GUIDed structures in the flash, so
- * search for them
- */
- pc_system_parse_ovmf_flash(ptr, size);
+ if (ovmf_supported()) {
+ /*
+ * OVMF places a GUIDed structures in the flash, so
+ * search for them
+ */
+ pc_system_parse_ovmf_flash(ptr, size);
+ }
x86_firmware_configure_sev(gpa, ptr, size);
}
void x86_firmware_reconfigure(hwaddr gpa, void *ptr, int size)
{
- invalidate_ovmf_parsed_metadata();
- pc_system_parse_ovmf_flash(ptr, size);
+ if (ovmf_supported()) {
+ invalidate_ovmf_parsed_metadata();
+ pc_system_parse_ovmf_flash(ptr, size);
+ }
x86_firmware_configure_sev(gpa, ptr, size);
}
diff --git a/hw/i386/pc_sysfw_ovmf-stubs.c b/hw/i386/pc_sysfw_ovmf-stubs.c
index edf890a525..08ec18b9b7 100644
--- a/hw/i386/pc_sysfw_ovmf-stubs.c
+++ b/hw/i386/pc_sysfw_ovmf-stubs.c
@@ -15,6 +15,11 @@
#include "qemu/osdep.h"
#include "hw/i386/pc.h"
+bool ovmf_supported(void)
+{
+ return false;
+}
+
bool pc_system_ovmf_table_find(const char *entry, uint8_t **data, int *data_len)
{
g_assert_not_reached();
diff --git a/hw/i386/pc_sysfw_ovmf.c b/hw/i386/pc_sysfw_ovmf.c
index 3244c17a7d..e6497fd7a7 100644
--- a/hw/i386/pc_sysfw_ovmf.c
+++ b/hw/i386/pc_sysfw_ovmf.c
@@ -36,6 +36,11 @@ static bool ovmf_flash_parsed;
static uint8_t *ovmf_table;
static int ovmf_table_len;
+bool ovmf_supported(void)
+{
+ return true;
+}
+
void invalidate_ovmf_parsed_metadata(void)
{
ovmf_flash_parsed = false;
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 7b0d0c54f5..2e41ca8b05 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -212,6 +212,7 @@ bool pc_system_ovmf_table_find(const char *entry, uint8_t **data,
int *data_len);
void pc_system_parse_ovmf_flash(uint8_t *flash_ptr, size_t flash_size);
void invalidate_ovmf_parsed_metadata(void);
+bool ovmf_supported(void);
/* sgx.c */
void pc_machine_init_sgx_epc(PCMachineState *pcms);
--
2.42.0
next prev parent reply other threads:[~2025-03-05 7:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 7:50 [PULL 0/3] Some refactoring/cleanups for cpu versions on microvms Ani Sinha
2025-03-05 7:50 ` [PULL 1/3] hw/i386: introduce x86_firmware_reconfigure api Ani Sinha
2025-03-05 7:50 ` Ani Sinha [this message]
2025-03-05 7:50 ` [PULL 3/3] microvm: do not use the lastest cpu version Ani Sinha
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=20250305075015.26892-3-anisinha@redhat.com \
--to=anisinha@redhat.com \
--cc=eduardo@habkost.net \
--cc=kraxel@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--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 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).