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 >