On Fri, Sep 12, 2025 at 02:29:16PM +0100, Daniel P. Berrangé wrote: > On Fri, Sep 12, 2025 at 03:25:08PM +0200, Gerd Hoffmann wrote: > > On Wed, Jul 09, 2025 at 02:30:07PM +0200, Gerd Hoffmann wrote: > > > Implement a ConfidentialGuestSupportClass for non-confidential VMs. > > > This allows the igvm support code work without sev/tdx. > > > > > > RfC: Not fully sure this is the best way to implement this. > > > Alternatively we could add this directly into the igvm backend and run > > > it in case no confidential guest support object is present. > > > > Started to look at this again. Noticed that at least simple native > > igvm files (with memory regions only) boot just fine without an > > ConfidentialGuestSupportClass. Which kind-of underlines that going for > > a pseudo-ConfidentialGuestSupportClass for native mode is maybe not the > > best design idea ... > > > > Nevertheless we'll go need target-specific code for some IGVM features. > > That is obviously the case for loading some custom initial CPU state. > > But also things like the memory map are not the same across targets, > > even though some targets might share an implementation (e820 on x86, > > fdt elsewhere). > > > > Suggestions how to wire that up best? > > I'm not familiar with the details of IGVM wrt varying technologies. > Consider that x86 can boot a guest non-confidential, SEV-SNP or TDX. > Do we have a single IGVM file that provides enough data for all > three scenarios, or does each deployment technology need a separate > IGVM file to be provided ?
You can have a single igvm file supporting all platforms. take care, Gerd
