teach Propolis a -v flag with Git metadata by hawkw · Pull Request #702 · oxidecomputer/propolis

hawkw · 2024-05-07T16:37:59Z

ixi note: since I'm basically taking the vergen bits Eliza had set up, I'm editing this PR in place after having clipped out the SMBIOS stuff. also it uses vergen 10.0 now rather than 6 or whatever it was. the below is my reworking Eliza's commit a bit given the different integration with the binaries, so it's .. pretty similar to the old one but also different.

Currently, Propolis, both -server and -standalone, opaquely run with no
hint available about the provenance of the binary. For binaries that
come from product software releases, this is basically fine, as those
packages include a sha256 of the packaged Propolis zone and one can work
from a binary to a source commit.

For any development-time experience, random propolis-standalones we've
left around, or VMM binaries one finds on a particularly scrumptious USB
stick in a parking lot, a `--version flag telling you where the binary
probably came from would go a long way.

This branch adds a build.rs script that uses the vergen crate
to emit information about the Git revision that Propolis was build from.
Now, we can generate a version string that describes the git branch,
commit hash, and commit depth. This is generated in a
propolis::version() function, which also includes the detected bhyve
and viona API versions at runtime. This results in version strings like:

propolis-standalone v0.1.0-930 (DIRTY b428c40ef) eliza/somebios-version, bhyve API v18, viona API v6

In addition to the --version flag described above, this commit also
has propolis-server and propolis-standalone print version information
when run in a way that they will later run a VM. In release software
this can provide evidence of a propolis-server which generated a log
file. For the rest of us, hopefully the log line isn't lost to
backscroll if an issue has occurred..

The start of both -server and -standalone logs will now have something like:

Aug 12 02:06:49.389 INFO Running v0.1.0-932 (c948d02) eliza/somebios-version, bhyve API v18, viona API v6

luqmana · 2024-05-07T18:16:36Z

Version in SMBIOS tables aside for now, I like having this available via just --version. Great for double checking one-off binaries laying about!

hawkw · 2024-05-07T18:50:16Z

Since this shouldn't actually result in differing versions after live migration (per @pfmooney's comment in #701 (comment)), I'm marking this as ready for review.

pfmooney · 2024-05-07T19:03:29Z

+            manufacturer: SmbString::default(),
+            product_name: SmbString::default(),
+            version: SmbString::try_from(crate::version())
+                .expect("version string should not contain NULs"),


If we remove the bhyve API version from the string, we could include this condition as part of the version() unit tests

rmustacc · 2024-05-08T03:25:47Z

So I'm not sure if we want this going in SMBIOS per se. I get the benefit as a developer, but I'm less sold from a customer perspective. What are the semantics of the version that they should use? Are we committing to the format? This leaks information about the host version in a much more concrete way and I'll admit I expected this to be something about the virtual machine itself or something about the overall system as opposed to the virtualization part of it.

For example:

qemu: Version: pc-i440fx-jammy
AWS Nitro doesn't use it at all
On both Gigabyte and Dell systems (AMD and Intel respectively) I see it as being the string 001/01.

I think if we want to say something about propolis itself, then this would be where we want the actual hardware platform revision to go in as this seems much more about the virtual platform.

Presently, the BIOS version string in Propolis' SMBIOS tables is hardcoded to a default value. It would be nice to instead use the OVMF version for the BIOS version string. Because Propolis' understanding of bootroms is just a path on the filesystem to some kind of file, it's not aware of the OVMF version, or, indeed, that the bootrom even *is* OVMF (and it could conceivably be anything). Therefore, the bootrom version must be provided externally, such as by the Oxide control plane in the case of `propolis-server`, or by the user when running standalone. This PR adds a config field `bootrom_version` to the TOML config files for `propolis-server` and `propolis-standalone` which can be used to provide a value for the bootrom version string. If the version string is not provided, Propolis will continue to use the current default values. I considered changing the config format to move the `bootrom` path field and `bootrom_version` string field into a `bootrom` table, as in: ```toml [bootrom] path = "/path/to/OVMF_CODE.fd" version = "edk2-stable202402" ``` However, this would break existing configs, and I don't think it's so much nicer than ```toml bootrom = "/path/to/OVMF_CODE.fd" bootrom_version = "edk2-stable202402" ```` to justify breakage. I'm happy to change the format if others disagree. Along with #702, this branch implements the changes described in #701.

hawkw · 2024-05-08T16:07:26Z

@rmustacc I'm also not totally sure what the intended use-case of this is --- perhaps @luqmana (who opened issue #701 for adding this) has thoughts about why we would want to expose Propolis versions in SMBIOS?

Presently, the BIOS version string in Propolis' SMBIOS tables is hardcoded to a default value. It would be nice to instead use the OVMF version for the BIOS version string. Because Propolis' understanding of bootroms is just a path on the filesystem to some kind of file, it's not aware of the OVMF version, or, indeed, that the bootrom even *is* OVMF (and it could conceivably be anything). Therefore, the bootrom version must be provided externally, such as by the Oxide control plane in the case of `propolis-server`, or by the user when running standalone. This PR adds a config field `bootrom_version` to the TOML config files for `propolis-server` and `propolis-standalone` which can be used to provide a value for the bootrom version string. If the version string is not provided, Propolis will continue to use the current default values. I considered changing the config format to move the `bootrom` path field and `bootrom_version` string field into a `bootrom` table, as in: ```toml [bootrom] path = "/path/to/OVMF_CODE.fd" version = "edk2-stable202402" ``` However, this would break existing configs, and I don't think it's so much nicer than ```toml bootrom = "/path/to/OVMF_CODE.fd" bootrom_version = "edk2-stable202402" ```` to justify breakage. I'm happy to change the format if others disagree. Along with #702, this branch implements the changes described in #701.

luqmana · 2024-05-08T20:03:05Z

@rmustacc I'm also not totally sure what the intended use-case of this is --- perhaps @luqmana (who opened issue #701 for adding this) has thoughts about why we would want to expose Propolis versions in SMBIOS?

No particular use case beyond just tracking whether we wanted to hardcode it at all. I do think @rmustacc's point about identifying the "Virtual Platform" revision would make more sense. Either way, there's clearly a couple ways to go here.

Thanks for putting this together so quickly @hawkw and I think if we drop the SMBIOS bits it's still worth merging just to have the --version output. In which case, let's drop the bhyve api version from it as well. @pfmooney made the good point that that's not some fixed version tied to the binary itself. If anything, ApiVersion::current() would be more useful as quick way to figure out what a random propolis binary was built against without having to find the corresponding commit first.

hawkw · 2024-05-08T21:04:57Z

I'll go ahead and back out the SMBIOS changes, I agree that it's nice to get commit information in the CLI version output regardless of what we do about SMBIOS. And I think including the bhyve version we were built against, rather than the current version detected at runtime, seems like a good call.

iximeow

just to note: I think it'd be nice to have this at some point even though we've since gotten programmable type 1 table information. I agree that the SMBIOS version makes more sense as the virtual platform version, but that doesn't preclude making --version a useful CLI argument

hawkw · 2025-12-09T22:21:03Z

just to note: I think it'd be nice to have this at some point even though we've since gotten programmable type 1 table information. I agree that the SMBIOS version makes more sense as the virtual platform version, but that doesn't preclude making --version a useful CLI argument

Yup, I would be happy to resurrect some of those bits at some point.

Currently, Propolis, both -server and -standalone, opaquely *run* with no hint available about the provenance of the binary. For binaries that come from product software releases, this is basically fine, as those packages include a sha256 of the packaged Propolis zone and one can work from a binary to a source commit. For any development-time experience, random `propolis-standalone`s we've left around, or VMM binaries one finds on a particularly scrumptious USB stick in a parking lot, a `--version flag telling you where the binary probably came from would go a long way. This branch adds a `build.rs` script that uses [the `vergen` crate][1] to emit information about the Git revision that Propolis was build from. Now, we can generate a version string that describes the git branch, commit hash, and commit depth. This is generated in a `propolis::version()` function, which also includes the detected bhyve and viona API versions at runtime. This results in version strings like: ``` propolis-standalone v0.1.0-930 (DIRTY b428c40) HEAD, bhyve API v18, viona API v6 ``` In addition to the `--version` flag described above, this commit also has propolis-server and propolis-standalone print version information when run in a way that they will later run a VM. In release software this can provide evidence of a propolis-server which generated a log file. For the rest of us, hopefully the log line isn't lost to backscroll if an issue has occurred.. [1]: https://docs.rs/vergen

iximeow · 2026-08-12T02:04:11Z

having talked with Eliza i'm cordycepsing this PR into putting version information into non-SMBIOS places

iximeow · 2026-08-12T02:15:06Z

@leftwo 🎁 finally the random propolis-servers that we run on bench sleds will tell us what they are :)

hawkw mentioned this pull request May 7, 2024

Accurate versions in SMBIOS tables #701

Open

luqmana reviewed May 7, 2024

View reviewed changes

Comment thread lib/propolis/src/lib.rs Outdated

hawkw marked this pull request as ready for review May 7, 2024 18:49

hawkw requested a review from pfmooney May 7, 2024 18:49

pfmooney reviewed May 7, 2024

View reviewed changes

hawkw mentioned this pull request May 8, 2024

Add SMBIOS bootrom version to config files #703

Merged

iximeow reviewed Dec 9, 2025

View reviewed changes

Comment thread lib/propolis/src/lib.rs Outdated

Comment thread lib/propolis/src/firmware/smbios/table.rs Outdated

hawkw and others added 2 commits August 12, 2026 01:40

info the version at start, fix test

c948d02

iximeow force-pushed the eliza/somebios-version branch from 934eb94 to 90a2bc4 Compare August 12, 2026 02:03

ope errors are important too

eb888d1

iximeow changed the title ~~populate SMBIOS system version with Git metadata~~ teach Propolis a -v flag with Git metadata Aug 12, 2026

iximeow requested a review from leftwo August 12, 2026 02:14

i have literally never seen cargo xtask style before

b1b747d

Uh oh!

Conversation

hawkw commented May 7, 2024 • edited by iximeow Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

luqmana commented May 7, 2024

Uh oh!

Uh oh!

hawkw commented May 7, 2024

Uh oh!

Uh oh!

Uh oh!

pfmooney May 7, 2024

Choose a reason for hiding this comment

Uh oh!

rmustacc commented May 8, 2024

Uh oh!

hawkw commented May 8, 2024

Uh oh!

luqmana commented May 8, 2024

Uh oh!

hawkw commented May 8, 2024

Uh oh!

iximeow left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

hawkw commented Dec 9, 2025

Uh oh!

iximeow commented Aug 12, 2026

Uh oh!

iximeow commented Aug 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

hawkw commented May 7, 2024 •

edited by iximeow

Loading