Hi Gerd,
On Thu, Mar 13, 2025 at 01:05:13PM +0100, Gerd Hoffman wrote:
> // regions_addr points to an array of this structure
> struct vmfwupdate_regions {
> uint64_t size;
> uint64_t src_addr; // source address (before update)
> uint64_t dst_addr; // destination address (after update)
> uint64_t flags; // control bits
> };
>
> // flags
> #define VMFWUPDATE_REGION_FLAG_COPY // data must be copied
> #define VMFWUPDATE_REGION_FLAG_ZERO // dest must be cleared
> #define VMFWUPDATE_REGION_FLAG_MEASURE // data must be measured
>
> (1) is still not covered.
> (2+3) can be handled with FLAG_ZERO regions, with and without
> FLAG_MEASURE.
> (4) Alex already pointed that the cpuid page is special, guess we
> need additional flags for those oages.
That looks better, when the host VMM guarantees the order in which it
translates these regions into VM setup calls, then it is a step
forward. Although there more things to keep in mind, like the guest
policy and SEV status parameters.
> 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.
Regards,
Joerg
