The uuid is being correctly validated in smbiostbl.c:smbios_type1_initializer() so there's no need to do it again. An fprintf to stderr there indicatiing it is invalid is fine, and the assert on a return from smbios_build() can be changed into an exit(1).

the least effort would be to not touch this review and commit the already reviewed patch to main.

Looks fine, and preserves #GP on writes.

Want to abandon this one and re-submit ?

This is worth having.

Looks good.

Rod, why is your opinion so important ?

Fixes the issue for me.

Looks fine: please fix the #define on submit.

The older bhyve edk2 f/w can be built with up to gcc7, if gcc48 needs to be killed off

(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222233#c7)

Maybe ping ctuffli/imp for nvme.h, since that may involve removing other unecessary __packed's

Yes for the bhyve parts.

Good catch rew :)

Thanks for doing this; a long overdue change.

D28962 now committed with 95331c228a39

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.