Thank you for finding and proposing fixes for these issues!
In the future, submitting the changes with more context (e.g., git format-patch -U999999 --stdout other-branch > change.diff) helps speed things along.

I like the overall direction of this, but this has a substantial foot print to review. Is there some way to smoke test some of this?

I done goofed and accepted this as bhyve. Please wait for one of the others to weigh in as well.

LGTM, but are there other places in the kernel that should now know about the new offset?

The EUI64 exists to uniquely identify a drive, and this fix doesn't change that. The value is reported in the Namespace data, and is not a load-bearing value from a protocol perspective. If someone had automated logging and inventory setup for their systems and were explicitly setting the EUI64, they might notice this change.

Thanks for finding this and fixing it.

I like the approach of defining the options in each module (e.g., machdep), but it would be interesting to see what this approach looks like for one of the storage devices (e.g., NVMe) which have both their own options as well as the common blockif options.

Assuming you restore the declaration of val as @bnovkov suggested, LGTM.

Simplify per review feedback

rebase

Update based on review feedback

Report unexpected nvlist type as an error per review feedback

Update based on review feedback + rebase to main

Address review feedback and rebase.

Rebase

Update change from review feedback

Remove invalid mdoc macro

Add link to man page for diskhealth

Update with jrm@ review feedback

Fix trailing whitespace

Address review feedback

Note this fixes the issue reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282237 and with commit 7631790422464de1aec309018e2c444defe5f629 differently, but the fix mirrors what SmartOS/illumos did to minimize diff's between the various bhyve implementations.

Remove kasserts and move memset to central location

OK. I had that in because most (all?) calls to this function do a KASSERT(cmd != NULL) immediately afterwards. Should I delete the KASSERTs in the calling functions as well?

Address review feedback

You are correct. I had (mistakenly) convinced myself that pattern occurred in more places. I'll move as suggested and delete the occurrence in amdvi_inv_domain

Other functions call amdvi_get_cmd_tail() prior to calling the functions which would then format the command entry. Putting the memset() in amdvi_get_cmd_tail() would clear the command entry twice.

This patch worked for me as well and doesn't seem to bother Windows guest, but they don't seem to need it like the Linux ones do.