We should setup dependabot.

New version has nicer debug printing for enums.

Some new PRs have a smattering of different copyright fields. Lets clean them all up to use SPDX-License-Identifier along with making them consistent.

Lets be consistent and have doc comments start with a capital letter and end with a period. Which also, matches the styling used by the official rust docs.

Instead of having just a stable merge, offer an unstable merge that attempts to deduplicate PAGE_DATA structures between different compatibility masks. A user could use this unstable_merge to make the IGVM file as small as possible, then perform another pass to generate the launch measurement.

It looks like commit 44708fd produced a release (which is also pushed on crates.io: https://crates.io/crates/igvm/0.1.6), but there isn't the tag pushed in this repository.

For non-Rust consumers it would be nice to have a C API for the parser. This can be gated behind a feature.

Current thoughts consist of perhaps having a to_c_struct function that would provide the igvm_defs C struct along with a void* of available filedata, along with iteration functions on IgvmFile to move forward/backwards thru different structures.

The crate should implement ID block generation for SNP given a list of headers.

The specification states that for page data structures with file offset zero are measured with hardware zero pages if possible:

If the file offset is zero, then a page of zeroes is to be loaded. If the page contents are to be measured, and the underlying platform supports measured zero pages as a native page type, then the loader must request this page type; otherwise, the loader must generate a page of zeroes to load as the page contents.

However, this is incorrect. These pages should be treated as normal private pages with contents of zero. A future page type will be required for specifying hardware zero pages, on platforms that support it.

Gating say an enum variant behind the unstable feature causes open_enum to gate the derived enum correctly, but not the debug impl. This blocks us from having nice intra-doc links because it's quite annoying to then gate any doclink comments in that enum variant.

For example:

#[open_enum]
#[derive(AsBytes, FromBytes, FromZeroes, Debug, Clone, Copy, PartialEq, Eq)]
#[repr(u32)]
pub enum IgvmVariableHeaderType {
    ....
    #[cfg(feature = "unstable")]
    #[cfg_attr(docsrs, doc(cfg(feature = "unstable")))]
    IGVM_VHT_MEMORY_STATE_PARAMETER = 0x313,
}

becomes

    #[cfg(feature = "unstable")]
    #[cfg_attr(docsrs, doc(cfg(feature = "unstable")))]
    pub const IGVM_VHT_MEMORY_STATE_PARAMETER: IgvmVariableHeaderType = IgvmVariableHeaderType(787);
    ....
impl ::core::fmt::Debug for IgvmVariableHeaderType {
    fn fmt(&self, fmt: &mut ::core::fmt::Formatter) -> ::core::fmt::Result {
        #![allow(unreachable_patterns)]
        let s = match *self {
        ....    
            Self::IGVM_VHT_DEVICE_TREE => stringify!(IGVM_VHT_DEVICE_TREE),
            Self::IGVM_VHT_MEMORY_STATE_PARAMETER => stringify!(IGVM_VHT_MEMORY_STATE_PARAMETER),
        ....

which doesn't compile because the type must also be cfg(feature) attr-ed in the emitted debug impl

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.

Today it requires manual steps on a machine to do this, rather than having a GH actions pipeline that can be run.

Add flags for memory structures along with adding a flags type for device tree. This allows specifying memory ranges as shared along with other options in the future.

Additionally, update the device tree nodes with a flags field.