On Mon, Mar 18, 2024 at 03:59:31PM +0000, Roy Hopkins wrote: > On Fri, 2024-03-01 at 17:10 +0000, Daniel P. Berrangé wrote: > > On Tue, Feb 27, 2024 at 02:50:15PM +0000, Roy Hopkins wrote: > > > IGVM support has been implemented for Confidential Guests that support > > > AMD SEV and AMD SEV-ES. Add some documentation that gives some > > > background on the IGVM format and how to use it to configure a > > > confidential guest. > > > > > > Signed-off-by: Roy Hopkins <roy.hopk...@suse.com> > > > --- > > > docs/system/igvm.rst | 58 +++++++++++++++++++++++++++++++++++++++++++ > > > docs/system/index.rst | 1 + > > > 2 files changed, 59 insertions(+) > > > create mode 100644 docs/system/igvm.rst > > > > > > > +Firmware Images with IGVM > > > +------------------------- > > > + > > > +When an IGVM filename is specified for a Confidential Guest Support > > > object > > > it > > > +overrides the default handling of system firmware: the firmware image, > > > such > > > as > > > +an OVMF binary should be contained as a payload of the IGVM file and not > > > +provided as a flash drive. The default QEMU firmware is not automatically > > > mapped > > > +into guest memory. > > > > IIUC, in future the IGVM file could contain both the OVMF and SVSM > > binaries ? > > > > I'm also wondering if there can be dependancies between the IGVM > > file and the broader QEMU configuration ? eg if SVSM gains suupport > > for data persistence, potentially we might need some pflash device > > exposed as storage for SVSM to use. Would such a dependancy be > > something expressed in the IGVM file, or would it be knowledge that > > is out of band ? > > > Yes, the IGVM file can indeed contain both OVMF and SVSM binaries. In fact, > that > is exactly what we are doing with the COCONUT-SVSM project. See [1] for the > IGVM > builder we use to package OVMF, bootloader components and the SVSM ELF binary. > > Data persistence is something that is definitely going to be needed in the > SVSM. > At present, this cannot be configured using any of the directives in the IGVM > specification but instead requires QEMU to be configured correctly to support > the application embedded within the IGVM file itself. You could however > populate > metadata pages using IGVM that describe the storage that is _expected_ to be > present, and validate that within the firmware itself. > > The real value from IGVM comes from the ability to describe the initial memory > and initial CPU state which all forms part of the launch measurement and > initial > boot procedure, allowing the expected launch measurement to be calculated > from a > single IGVM file for multiple virtualisation stacks or configurations. Thus, > most of the directives in the IGVM file directly have an effect on the launch > measurement. I'm not sure configuring a storage device or other hardware > configuration fits well with this.
Yeah, I can understand if IGVM scope should be limited to just memory and CPU setup. If we use the firmeware descriptor files, we could define capabilities in that to express a need for a particular type of persistent storage to back the vTPM. So having this info in IGVM files isn't critical. > > Finally, if we think of the IGVM file as simply yet another firmware > > file format, then it raises of question of integration into the > > QEMU firmware descriptors. > > > > Right now when defining a guest in libvirt if you can say 'type=bios' > > or 'type=uefi', and libvirt consults the firmware descriptors to find > > the binary to use. > > > > If the OS distro provides IGVM files instead of traditional raw OVMF > > binaries for SEV/TDX/etc, then from libvirt's POV I think having this > > expressed in the firmware descriptors is highly desirable. > > > > Whether IGVM is just another firmware file format or not, it certainly is used > mutually exclusively with other firmware files. Integration with firmware > descriptors does seem to make sense. > > One further question if this is the case, would we want to switch from > specifying an "igvm-file" as a parameter on the "ConfidentialGuestSupport" > object to providing the file using the "-bios" parameter, or maybe even a > dedicated "-igvm" parameter? If the IGVM format is flexible enough that it could be used for any VM type, even non-confidential VMs, then having its config be separate from ConfidentialGuestSUpport would make sense. If it is fundamentally tied to CVMs, then just a property is fine I guess. Probably best to stay away from -bios, to avoid overloading new semantics onto a long standing argument. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|