There's some scenarios where you'd want to use IGVM to launch a non-isolated guest. This is to allow a consistent launch packaging format to decouple loader code from the rest of the virtual machine manager (VMM). Today, the platform types don't have a good way to express this; there only exist types for isolated guests such as Hyper-V's VSM, AMD's SEV-SNP, etc.
This proposal is to rename the INVALID type to a Native type. This would mean that the VMM is free to load the data described by the IGVM file in any way it sees fit. There would be no measurement support since this is not the launch of an isolated VM. The key point here is that the platform type described by the IGVM file defines the load primitives used to bring the VM to life. Should it be loaded via the TDX module, or via the PSP, or natively into the VMM's infrastructure? It doesn't make any promise about what the VMM is willing to do to support the guest, because that can be determined at runtime.
Note that this does not mean Native IGVM files are not cross compatible between different VMMs. A guest may need to make sure that headers used support the least common denominator (and of course being able to run with potentially different VMM host interfaces), but already information about the guest is surfaced via runtime provided parameters, with many headers being applicable to non-isolated guests.
One point of discussion is initial launch context of VPs, especially the BSP. One proposal is to continue to allow the VSM definition where register state is provided by key/value pairs. If no VP context structure is specified, then the BSP will be placed into the architectural reset state.
Alternatively we could only support the architectural reset state. However, I think having the flexibility to allow an IGVM file to launch in the non-architectural state is required, for launch performance (run directly the entry point of a guest, rather than going thru different transitions) and flexibility.
There's some scenarios where you'd want to use IGVM to launch a non-isolated guest. This is to allow a consistent launch packaging format to decouple loader code from the rest of the virtual machine manager (VMM). Today, the platform types don't have a good way to express this; there only exist types for isolated guests such as Hyper-V's VSM, AMD's SEV-SNP, etc.
This proposal is to rename the
INVALIDtype to aNativetype. This would mean that the VMM is free to load the data described by the IGVM file in any way it sees fit. There would be no measurement support since this is not the launch of an isolated VM. The key point here is that the platform type described by the IGVM file defines the load primitives used to bring the VM to life. Should it be loaded via the TDX module, or via the PSP, or natively into the VMM's infrastructure? It doesn't make any promise about what the VMM is willing to do to support the guest, because that can be determined at runtime.Note that this does not mean Native IGVM files are not cross compatible between different VMMs. A guest may need to make sure that headers used support the least common denominator (and of course being able to run with potentially different VMM host interfaces), but already information about the guest is surfaced via runtime provided parameters, with many headers being applicable to non-isolated guests.
One point of discussion is initial launch context of VPs, especially the BSP. One proposal is to continue to allow the VSM definition where register state is provided by key/value pairs. If no VP context structure is specified, then the BSP will be placed into the architectural reset state.
Alternatively we could only support the architectural reset state. However, I think having the flexibility to allow an IGVM file to launch in the non-architectural state is required, for launch performance (run directly the entry point of a guest, rather than going thru different transitions) and flexibility.