On Wed, Mar 20, 2024 at 03:45:24PM +0000, Roy Hopkins wrote: > On Mon, 2024-03-18 at 16:21 +0000, Daniel P. Berrangé wrote: > > 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. > > I'll need to look into firmware descriptor files as I'm unfamiliar with how > they > work. Would I need to make any additions to this patch series to support this > in > QEMU? Or is this all handled by libvirt?
Probably little more than change docs/interop/firmware.json to add 'igvm' as a FirmwareDevice option to indicate this is a new way of exposing it to the guest. At some point we might also want to expand FirmwareFeature eg to report a "vtpm" feature. > > > 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. > > Currently, the IGVM specification only contains support for confidential > platforms. It could theoretically be used for non-confidential platforms but > that would require changes to the IGVM specification itself to support this. I > don't think it makes sense to extend this to non-confidential VMs until the > specification supports this, so I'll leave it as a property of > ConfidentialGuestSupport. Sounds good. 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 :|