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?
VMM does not care but UKI which the guest brings in would since a IGVM container would be part of not .efifw section but .igvm section. As I understood the current > documentation the defined behavior is to copy the guest-provided > FW-image to the BIOS region, no? In the latest proposal which Gerd has suggested, VMM does not know or care if its bios region or not or what kind of image it is copying. The guest provides the target private address at which to copy the blob from the shared memory region. So the FUKI which bundles a fw image would provide 4G-size for x86 as the target physical address. A FUKI that bundles an IGVM can provide something else. > > > 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 >
