This ends up running before PCI assigns resource addresses, so we get the very first lowmem_limit address. I don't know any reason that would cause problems for PCI (it does not appear to), but just an FYI for reviewers.

I think it would be good to document Bhyve's physical memory layout and how registered mem/fallback ranges work in a single place; I had some trouble piecing it together across multiple files and libraries.

The VM Gen. ID spec does say the device should have a unique _HID of some kind but leaves the content and form unspecified. Here we have followed the HyperV convention of a readable English named with explicit version number suffix. I picked zero because this is only a partial implementation, but the number is arbitrary. Any sane VM Gen driver will match on _CID or _DDN.

I've defined _HID as a Method returning a string, rather than a bare named string, as a hack to work around a stupid naming guideline in the iasl compiler for _HID (but not _CID) names. The guideline clearly does not matter to guests — you could say HyperV is the reference implementation of this spec, and HyperV uses a non-canonical _HID. Every operating system seems to run just fine on Azure.

(Canonically, _HID is one of three forms: AAA#### (A is any uppercase ASCII letter, # is any hexadecimal number`, NNNN#### (N is uppercase ASCII or decimal digits, # as before), or ACPI#### (here, "ACPI" is the literal characters, # as before). Obviously this would be very limiting in communicating anything meaningful about the "hardware" implementation in the _HID.)

The spec doesn't say ADDR must be a method, just that it must evaluate to a Package of two integers; that means it could just be a named Package object.
So more simply, we could instead specify it as:

Name (ADDR, Package (0x02)
{
  0x%08x,
  0x%08x
})

That would be tolerable for our vmgenc(4) and any spec-compliant guest implementation, but I haven't audited operating systems explicitly (Linux would be easy to check; Windows might be impossible). Leaving it as a Method is also, IMO, harmless.

Since you're in here: "... and then compiling them ..."

Since this is going to be an address, shouldn't it be uint64_t?

For PCI it does take away a 1GB-aligned region, and won't allow 512MB BARs to be used. This may not be that much of an issue, but I think it could be avoided by putting the UUID into high ROM space. There is 16MB available for this and EFI only uses 2MB max.

That's far enough away from anything I'm touching I'm inclined to leave it be in this revision, but feel free to do a drive-by typo fix in the comment if you feel strongly about it :-).

No -- we want to allocate in the PCI hole, which is by definition below 4GB.

That's a good consideration, thanks.

Do we have any existing scheme for allocating ROM space, or is it just ad-hoc? Also, is the ROM region required to be mapped UC? The spec suggests the UUID should not share a page with anything requiring UC mapping, although it's unclear to me why that would possibly matter.

One other possibility would just be to allocate the UUID after the PCI buses in the PCI hole. Usually there is plenty of space there, unless a guest needs very large 32-bit BARs. But I like the suggestion to use ROM space for this instead. The important part is that the UUID doesn't end up on a page included as ordinary "Memory" in SMAP/e820.

ROM space allocation is ad-hoc.

I suspect it is required to be mapped UC since at least on real h/w it's outside the coherency domain. But, as you mentioned this does seem a strange requirement and may not be enforced.

Fair enough. A comment to that effect would be nice. :-)

You might want to remove NETAPP from the copyrights :)

Ah, thanks. rS359959