On Thu, Mar 13, 2025 at 7:01 PM Jörg Rödel <j...@8bytes.org> wrote:
>
> 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.
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. To that end, we can make small
changes to the hypervisor side so that instructions can be executed by
IGVM loaded in guest memory. My talk in the KVM Forum was "empowering
the guest" :-)
>
> Regards,
>
> Joerg
>
