On Thu, Mar 13, 2025 at 4:57 PM Jörg Rödel <j...@8bytes.org> wrote:
>
> On Thu, Mar 13, 2025 at 04:39:15PM +0530, Ani Sinha wrote:
> > Right so what we are proposing is generic enough so that if the VM
> > wants to use an IGVM container as opposed to an actual firmware image
> > in a FUKI, that is totally possible. Then you need to have that IGVM
> > setup the memory in a well defined way like you suggest. Sure, the
> > IGVM is not passed through a command line but it can be loaded by the
> > guest in a well defined memory location and then its instructions can
> > be executed.
>
> That makes sense. In this scenario, how does the VMM detect that it got
> an IGVM image instead of a firmware image? As I understood the current
> documentation the defined behavior is to copy the guest-provided
> FW-image to the BIOS region, no?

Note that even with this approach where the hypervisor *thinks* it's
dealing with a real firmware, you can imagine a small rust based
firmware image that is loaded by the guest in the firmware region.
This tiny firmware then jumps to a well known address (chosen by the
guest) where IGVM is loaded and then starts executing the IGVM
instructions.

>
> > In our proposal, we do not want to dictate how the guest would want to
> > do that. So hopefully you see now that IGVM and our approach is not
> > mutually exclusive but can be complementary to each other.
>
> Fine with me. Just note that supporting the current non-IGVM process for
> confidential guests still causes the implicit ABI issue I mentioned
> before. But not being a KVM/QEMU maintainer I can live with that :)
>
> Regards,
>
>         Joerg
>


Reply via email to