Accurate versions in SMBIOS tables

[luqmana]

The version information in the BIOS (type 0) and System (type 1) tables are currently hardcoded. We could instead set them to the OVMF and propolis versions (/commit hash?), respectively.

[jclulow]

If you're going to include the commit hash it might also help to include the commit depth (as close to a monotonic revision number as you can get with git) like we do for Helios components. And, I guess, also the branch name, etc.

[hawkw]

Since Propolis itself is not published to crates.io, we don't really increment the crate version number very often --- it will almost always be 0.1.0. I think the Git metadata is much likelier to be useful.

We may also want to include the bhyve API version in a system version string?

[pfmooney]

One point worth noting: If we put version data about propolis and/or bhyve in the SMBIOS tables, it will potentially become out of date when the instance is live-migrated.

[hawkw]

Oh, hmm, that's a good point @pfmooney. It would sure be a shame to break guests just because we migrated to a VMM built from a different Git commit.

I do have a branch implementing the Propolis version in the type 1 table (#702), but I'm happy to drop it if we think this is actually a bad idea.

[hawkw]

Regarding the OVMF version, since Propolis just gets the bootrom from a path to an arbitrary file in the TOML config, it doesn't have an easy way to know what the OVMF version is. Probably, we want to make the reported BIOS version configurable in the config file, and ensure that it's set to whatever OVMF version Propolis gets?

[pfmooney]

I'm happy to drop it if we think this is actually a bad idea.

I don't think it's a bad idea, but rather one of limited utility, at least for now. I'd rather not clutter up the build until we have a clear reason.

Probably, we want to make the reported BIOS version configurable in the config file, and ensure that it's set to whatever OVMF version Propolis gets?

At some point, I imagine we'll have some sort of selectable bootrom profiles (complete with version metadata), but until then, setting it via the config is probably the right path. (And I wouldn't even bother with wiring it up in standalone)

[pfmooney]

It would sure be a shame to break guests just because we migrated to a VMM built from a different Git commit.

I don't believe this would actually be breaking. Once fw_cfg is fixed (a WIP) in propolis, we'll simply migrate the generated contents, so they remain fixed after the instance initialization code sets them the first time.

[rmustacc]

I missed the discussion here when I wrote up this comment in #702.

It would sure be a shame to break guests just because we migrated to a VMM built from a different Git commit.

I don't believe this would actually be breaking. Once fw_cfg is fixed (a WIP) in propolis, we'll simply migrate the generated contents, so they remain fixed after the instance initialization code sets them the first time.

While not breaking, this feels like it'd still be misleading to guests. Putting it in here suggests that customers should use it and key off of it semantically. So the fact that it can't be updated at run-time across a migration to reflect a change is a strong reason for me that this shouldn't be reflecting something that's non-static.

In the case of OVMF, I assume that the OVMF version migrates with the guest so that would be consistent? But I don't see how that can be the case at all for Propolis. So I think the question we should be asking is what is how does a customer use this usefully and how do we ensure it reflects the system as a whole that they are using versus a point in time snapshot of the virutalization impl.

[iximeow]

as I've taken over 702 to use the build-time version information for other purposes, I wanted to come back here too: I agree with rm that we probably don't want information about the VMM binary in SMBIOS (or otherwise directly expressed to guests) - I'm conceptually more open to it from propolis-standalone but similar "what does this mean given migration" applies..

for Type 1 tables: I do think it'd make sense to include something like a virtual platform identifier in SMBIOS - that is information a customer should probably use in a semantically interesting way and it also must remain constant across migration. maybe some combination of "Family" and "Version"? I don't know what that might mean in standalone (if anything), since I'm still thinking about "the virtual platform version" as something that is a concept in Nexus and is compiled into some VM spec. so for server it would mean including a string in an instance spec, simple enough! but for standalone ... shrug?

for Type 0 tables: especially if/when virtual platforms cover selecting particular OVMF_CODE.fd images, it seems like we'd want to reflect that in BIOS Version and possibly BIOS Release Date somehow? in both cases I imagine them as reflecting arbitrary information we make up to communicate "this VM has a different OVMF build" and potentially indicating interesting information about the build used to boot a VM. that's all a stretch, since to date we're not often patching OVMF...