setting the guest HyperV interface hides who we are

[iximeow]

in propolis-server and, soon, propolis-standalone (#1194), setting the guest hypervisor interface to hyperv replaces the bhyve byhve brand string at leaf 0x4000_0000`. that's fine and good, and normal even. but, we don't stamp the byhve brand string into leaf 0x4000_0100, which means that to guests we are indicating we are HyperV and nothing else, rather than following the Xen/KVM convention of "Hyper-V leaves at 0x4000_0000, our identifiers at 0x4000_0100".

it would be nice to be able to provide a list of hypervisor interfaces which both binaries can apply at increasing CPUID leaf offsets, like hv_interfaces = ["hyperv", "kvm", "bhyve"] or .. something like that. we probably can't just have hypervisor leaves like ["hyperv", "bhyve"], because from a brief survey of guest OSes it seems like folks typically only expect Xen and KVM to move their leaves around, and bhyve is expected either at 0x4000_0000 or not at all.

stealing the archaeology and some survey notes from a comment out of #1194:

    // There is some background here:
    // * Linux detects hypervisors like above, see `hypervisor_cpuid_bsae`,
    //   which does this and returns the leaf that matched a given brand string.
    // * FreeBSD does the same basic approach at
    //   `identify_hypervisor_cpuid_base()`, looking for the first hypervisor
    //   brand string that matches one of the signatures in `vm_cpuids`.
    // * illumos in particular takes the above approach to look for the Xen
    //   signature.
    //
    // The history seems to be that in 2008, Xen added support for presenting
    // Hyper-V enlightenments in support of Windows guests. That's Xen commit
    // 39f97ffa2. This also placed the "normal" Xen hypervisor leaves at
    // 0x40000100 to query Xen rather than querying the reading back the Hyper-
    // leaves lower down. Intel reserves all of 0x4xxxxxxx for hypervisors,
    // TODO: AMD may have only reserved 0x400000xx, or maybe it has since become
    // more.
    //
    // In 2010, to detect Xen vs Hyper-V correctly, Linux got a a "check every
    // 0x100'th leaf" loop in `xen_cpuid_base()` with commit bee6ab53e6.
    // Allegedly a VMWare knowledge base item about detecting virtualization
    // platforms also included a mention of checking every 0x100'th leaf for
    // hypervisor signatures, but the knowledge base entry has since been lost
    // to the sands of time; this is only inference from FreeBSD and mailing
    // list posts.
    //
    // Later, this loop was generalized to all hypervisor detection in Linux and
    // things start looking much closer to how they are today. illumos, for its
    // part, currently only looks for Xen in the upper hypervisor leaves.
    //
    // So: one could imagine Hyper-V-then-KVM brand strings, such as QEMU
    // presumably offers when providing Hyper-V enlightenments. Should we be
    // Hyper-V-then-byhve? Hyper-V-then-KVM-then-bhyve may be technically viable
    // too. Other orderings are mostly a test of guest tolerance for *weird
    // things*.

it seems plausible that Linux would correctly identify leaves in the order [hyperv, bhyve] as "bhyve with hyperv characteristics", but I'm not sure what Windows would think at all, not sure I've properly understood what the BSDs would do, and know for sure that illumos currently only looks for Xen at higher leaves.