FYI the cumulative pfsense wireguard changes are in D28962

There's a more complete fix for this in the pfsense repo, that also stores the source address so CARP destination addresses will work:

https://github.com/pfsense/FreeBSD-src/commit/1940e7d3

The #if 0 debug code in vtnet_rxq_csum_data_valid could be removed and the unused parameter dropped, but not essential for this review.

The 64-bit issue is still present in the updated EDK2 (and being worked on), but moving off python2/gcc48 is a more pressing issue.

I tested all 3 ioapic diffs with a FreeBSD 12.2 guest on -current, with MSI/MSI-x disabled to force virtio-net and ahci to use level-triggered legacy IRQs. Some stress testing was done with those devices without any issue.

A separate review is fine.

Looks fine.

Change looks useful, thanks.

I've looked at all the non-vtnet phab changes, and looked at the diff of the cumulative vtnet changes.

I've updated the title and description.

Convert to use c11 atomics.

Only other thing I can think of is to install VARS.fd as read-only since it's use is as a template and not a location for vars. But, this can be done later (as can cutting over to an edk2 stable tag)

I'm not seeing those files in 80072.

I'm ok with this to go in to CURRENT and any remaining debug to occur there.

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