standalone: support guest hv interface options

[iximeow]

approximately twenty billion years ago (February last year) #849 saw us grow support for presenting Hyper-V as the guest hypervisor interface. this came with plumbing it into propolis-cli with the new --hyperv flag. we since overlooked adding that plumbing into propolis-standalone, where i found myself wanting it this week!

i'd fully forgotten that as-merged in 725eb8e,

Once the stack has some actual features, this may be better expressed as a table in the propolis-config-toml crate,

well ... this does that. i'm also just deleting the --hyperv flag here since i'm assuming no one other than me was using that anyway.

both propolis-standalone and propolis-cli now understand stanzas like

[main.hv_interface]
type = "hyperv"
reference_tsc = true

or

[main.hv_interface]
type = "bhyve"

the latter being somewhat less interesting today since it's just a way to write out the defaults in more words.

[iximeow]

this is incidental but the bhyve impl spells its type name as bhyve-guest-interface and the swapped order was bugging me.

[iximeow]

you are not seeing double! propolis-standalone/src/config.rs has a copy of this structure and comment.

I've only just realized that propolis-standalone does not use propolis-config-toml, and really they kind of just accept the same toml documents (for the most part) by intentional effort rather than shared code. I'm thinking about taking a shot at unifying those, but I want to do that a bit more intentionally (I dunno what all is in the propolis-config-toml dep tree and if it would make me sad rebuilding propolis-standalone). so, a copy for now.

[hawkw]

I've only just realized that propolis-standalone does not use propolis-config-toml, and really they kind of just accept the same toml documents (for the most part) by intentional effort rather than shared code

😬

[papertigers]

I cannot recall, but is this also related to the issue where we saw standalone wanted a u16 and server a string. I just ran into that the other day while working on fixing up vsock. So, you have my +1 on eventually unifying these.

[iximeow]

yeah, I don't remember which field it was but I also remember something wanting an integer literal where the other wanted a string..

[papertigers]

Given this comment, do any of these OSes pick and choose features from multiple hypervisor interfaces? In our case it seems that we are offering a standard bhyve hypervisor with the addition of just the hyperv tsc interface, could one later also gain some feature of kvm and be a bhyve-hyperv-kvm mix? If so, do you think HypervisorInterface is expressive enough to encapsulate that, or is that a bridge we will cross later if/when we reach it?

[iximeow]

do any of these OSes pick and choose features from multiple hypervisor interfaces?

I think the answer is "yes but not consistently", and that more than just picking features, sometimes there are guest OS quirks based on the inferred hypervisor that come along into just features. so for example the behavior where Linux assumes that on bare x86 hardware you need some iommu features to have x2avic, but under hypervisors that are known to expose x2avic, you can just use it (if CPUID bits say it's there). that ends up (if memory serves) keyed off the last hypervisor in the list, and it's not really a "feature" in that you don't look at any hypervisor CPUID leaves other than "there's a kvm in there somewhere"

so HypervisorInterface, alone, I think is probably fine, but we find ourselves needing a list here (#1195) the container will need to change so we have something like

main.hv_interface = [
    { type = "hyperv", reference_tsc = true },
    { type = "bhyve" }
]

or.. however you spell the toml. we might(?) want to do that before turning on the TSC enlightenment for real, just so guests don't assume we actually are Hyper-V (though some guests would pick the first understood hypervisor anyway, so..)

[papertigers]

I just have one question I left, but otherwise this seems good to me!