Embed a machine-readable firmware version record in the DXE FV

[jstarks]

The host/VMM needs to identify the firmware image and check compatibility by inspecting the image bytes at load time, without executing it. There was no such record, so version and interface information could only be recovered by running the firmware.

Generate a fixed-layout MSVM_FIRMWARE_VERSION_INFO blob at build time (PlatformBuild.py) carrying a signature, git commit, dirty flag, base release prefix, and a human-curated firmware/VMM interface contract version. Embed it as a RAW freeform file, locatable by the host via the 'MVFW' signature or its file GUID.

[mebersol]

should we unify this with SmbiosPlatform? That version has been this for several years:

#define MAJOR_RELEASE_VERSION 4
#define MINOR_RELEASE_VERSION 1

[mebersol]

Maybe SMBIOS wants the release version

[maheeraeron]

Additional point, do we want to enhance or add any version numbers or schema to indicate an LKG for hibernate scenarios? i.e. if we reportedly break hibernate again, the flow would be to increment some number?

[jstarks]

Yes, I think SMBIOS should probably get a real version, which should probably match the release version. Probably good to take as a follow up (we also need the release version to be known before GitHub release time so that we can embed it).

[Javagedes]

github workflows can have a trigger for when a release happens. That trigger will provide the release information to the workflow, which can use it.

My suggestion is you make either a build variable or a command line argument in your platformbuild to set the github release value:

def AddCommandLineOptions(self, parserObj):
    parserObj.add_argument("--version", dest="version", type=str, default="0.0.1", help="...")

def RetrieveCommandLineOptions(self, args):
    self.version = args.version

and in the github repo do something like this. Either in one step or split the version detection into a different step:

- name: Build version
  shell: bash
  env:
    RAW_VERSION: ${{ github.event_name == 'release' && github.event.release.tag_name || '' }}
  run: |
    # If a release tag is available, strip a leading 'v'/'V' and reduce
    # to a bare X.Y.Z semver core. Otherwise omit --version entirely.
    VERSION_ARG=""
    if [[ -n "$RAW_VERSION" ]]; then
      CLEAN_VERSION=$(echo "$RAW_VERSION" | sed -E 's/^[vV]//' | grep -oE '^[0-9]+\.[0-9]+\.[0-9]+' || true)
      echo "Raw version:   $RAW_VERSION"
      echo "Clean version: ${CLEAN_VERSION:-<none>}"
      if [[ -n "$CLEAN_VERSION" ]]; then
        VERSION_ARG="--version $CLEAN_VERSION"
      fi
    else
      echo "No release tag available; building without --version."
    fi
    stuart_build -c MsvmPkg/PlatformBuild.py $VERSION_ARG <rest of args>

[jstarks]

Yes, I think something like that is fine. But I'd suggest we do that as a separate change, since it also gets into the question of what the version should be for the closed-source fork.

[maheeraeron]

We should probably all come to an agreement on how this number gets populated between closed source and open source. Is the intent that both pipelines will need to maintain the same major.minor version? We do have a static .json file in our CI folders that define this as the source of truth.

[jstarks]

I added a TOML file that defines the versions for open source. We definitely should figure out how to have a coherent versioning story between open and closed source.

[jstarks]

Thanks for the pointers, @Javagedes. That was a big help.

[jstarks]

With OpenVMM changes (not yet posted), we get this at VM load time:

0.007849014s INFO worker_new{ name="VmWorker" action="new"}: openvmm_core::worker::vm_loaders::uefi: mu_msvm UEFI firmware version release="26.0" interface=1.0 commit=464f30b6dada9fb08ff612f7f150e32dc9079b51-dirty official=false

Which I think is nice.