Hi, > > > Open question is what we do about IGVM. > > > > > > One option would be the guest vmfwupdate tool loading and parsing igvm, > > > preparing the region list, then invoke the update. Problem is that some > > > igvm feaures such as initial register state can not be easily supported > > > that way. > > > > > > We could also expect the hypervisor support igvm, so the guest can > > > simply load the file into memory and pass address and size to the > > > hypervisor. Either as option, say via VMFWUPDATE_REGION_FLAG_IGVM, or > > > mandatory, i.e. scratch the region list and use IGVM exclusively. > > > > This is of course up to the QEMU maintainers to decide, but I want to > > highlight that IGVM already solves all the problems mentioned above, > > including setting multiple memory regions of different type, special > > data pages (cpuid, secrets, id-blob, vmsa) and more. It defines the > > order of setup calls the VMM has to invoke for the new context and also > > works for multiple platforms like TDX, SNP, non-coco, and in the future > > ARM as well. > > My take on this is that instead of making the interface more complex, > let's empower the guest to use IGVM if they think they need more > guarantees around those things that IGVM solves very well today. QEMU > already has IGVM backend support.
Ok, assuming we allow the guest submit a IGVM image (which makes sense indeed, otherwise we'll probably end up re-inventing IGVM). How will the kernel hashes be handled then? I assume they will not be part of the igvm image, but they must be part of the launch measurement ... take care, Gerd
