Tests out fine on a Ryzen system.

Looks fine.

D24066 should be committed soon so one less obstacle for this work.

Can we keep the CSM one until the bitter end, and build it from the existing repo ?

No objection from bhyve's PoV.

EPT invalidation has been tidied up with rS367593 so this is fine to go in now (and is gating D26209)

A snapshot of the KVM unit tests, slightly modified to work with bhyve and Adam's change, is at https://people.freebsd.org/~grehan/kvm_unit_tests/kut.tgz

This should be fine.

btw many thanks for doing this.

This is incorrect: there should never be an exit for a membar access by a guest, hence the assert.

Would it be possible to cache the smr_seq_t instead of pmap->pm_eptgen ? One less atomic to increment.

an error from invept results in a panic

Ahh Windows :(

I did not check how the disk is opened by loader

Looks fine.

Could you give me some more information on where to find these patches and how to apply them?

counter(9) should be used to implement this.

Generic PCI ROM BIOS support in EFI might be a better solution for this (there is a version posted in the vga-bios patches a while back), with ROM extraction being a separate issue.

D24066 would cover the unmap code: this work could reuse that.

The Intel ACRN edk2 fork has a GVT GOP driver that may be suitable

https://github.com/projectacrn/acrn-edk2/tree/ovmf-acrn/OvmfPkg/GvtGopDxe

Thanks, looking at this now.

Thanks kib@, I can commit this.

I'm happy with this change but need to wait for maintainer approval before I commit it

In D26035#578286, @jhb wrote:

In D26035#578062, @grehan wrote:

Given the config file syntax will likely change but the "-f" option will be around forever, can a magic number or first-line metadata comment be used to distinguish this key/value file format from a future version ?

I would be fine with using a more obscure option for the flat config file (if we did long opts it could be a --flat-config or some such without a short letter even, but we don't do any long opts so not quite as straightforward to pick an obscure one). I don't really expect the syntax of that to change, but I think having '-f' be used for a more friendly UCL syntax might be more useful and I would be happy to leave "-f" free for the UCL thing to use. The UCL thing might itself include a version number as a field for the UCL parser to use that I think would permit some level of compatibility in the future.

Given the config file syntax will likely change but the "-f" option will be around forever, can a magic number or first-line metadata comment be used to distinguish this key/value file format from a future version ?

In D25396#565538, @chuck wrote:

As an update, there is work underway to significantly enhance bhyve configuration. Once that lands, it should make many of the concerns here easier to address.

bhyve bits look fine.

happy for a MFC in say 2 weeks after commit to head?

Nice change. Don't forget to update the man page.

That all sounds reasonable: looks fine to me.

I don't have a problem with the serial, f/w rev or model number parts of this.

Relevant guest commits:
https://github.com/torvalds/linux/commit/2420a0b1798d7a78d1f9b395f09f3c80d92cc588
https://github.com/openbsd/src/commit/d72f70aa5ac4d8ade3f10d3366ab796d8ea2b9c1