The AMD SEV build of EDK2 only emits a single file, intended to be
mapped readonly. There is explicitly no separate writable VARS
store for persisting non-volatile firmware variables.
This can be used with QEMU's traditional pflash configuration
mechanism by only populating pflash0, leaving pflash1 unconfigured.
Conceptually, however, it is odd to be using pflash at all when we
have no intention of supporting any writable variables. The -bios
option should be sufficient for any firmware that is exclusively
readonly code.
A second issue is that the firmware descriptor schema does not allow
for describing a firmware that uses pflash, without any associated
non-volatile storage.
In docs/interop/firmware.json
'struct' : 'FirmwareMappingFlash',
'data' : { 'executable' : 'FirmwareFlashFile',
'nvram-template' : 'FirmwareFlashFile' } }
Notice that nvram-template is mandatory, and when consuming these
files libvirt will thus complain if the nvram-template field is
missing.
We could in theory make nvram-template optional in the schema and
then update libvirt to take account of it, but this feels dubious
when we have a perfectly good way of describing a firmware without
NVRAM, using 'FirmwareMappingMemory' which is intended to be used
with QEMU's -bios option.
A third issue is in libvirt, where again the code handling the
configuration of pflash supports two scenarios
- A single pflash image, which is writable
- A pair of pflash images, one writable one readonly
There is no support for a single read-only pflash image in libvirt
today.
This all points towards the fact that we should be using -bios
to load the AMD SEV firmware build of EDK.
The only thing preventing us doing that is that QEMU does not
initialize the SEV firmware when using -bios. That is fairly
easily solved, as done in this patch series.
For testing I've launched QEMU in in these scenarios
- SEV guest using -bios and boot from HD
- SEV guest using pflash and boot from HD
- SEV-ES guest using -bios and direct kernel boot
- SEV-ES guest using pflash and direct kernel boot
In all these cases I was able to validate the reported SEV
guest measurement.
Daniel P. Berrangé (2):
hw/i386: refactor logic for setting up SEV firmware
hw/i386: support loading OVMF using -bios too
hw/i386/pc_sysfw.c | 24 +++---------------------
hw/i386/pc_sysfw_ovmf-stubs.c | 10 ++++++++++
hw/i386/pc_sysfw_ovmf.c | 27 +++++++++++++++++++++++++++
hw/i386/x86.c | 5 +++++
include/hw/i386/pc.h | 1 +
5 files changed, 46 insertions(+), 21 deletions(-)
--
2.33.1
