Fixed the space typo. Thanks for the patience.

I did a survey of GCE's bare metal machine series, as well as internal checking. All of them show smbios.system.serial of the form GoogleCloud-BM-${uuid}, as opposed to GoogleCloud-${uuid} for non-bare-metal VMs.

I've confirmed that rGa9e77eb7016df70723c208fc09fbd01ec23a732d resolves the issue in PR 292177, so abandoning this change.

At first glance https://reviews.freebsd.org/rGa9e77eb7016df70723c208fc09fbd01ec23a732d will fix this issue. I'll apply it to my copy of the tree and make sure it fixes the openssl crash since that's a nice repeatable crash case for the alignment issue. I should be able to get that done in the next day or two.

Incorporated your suggested change just moving the vfp_save_state and tested successfully. Thank you for your patience on this.

When I get a chance I'll fire up some bare metal vms and see what I get out of dmidecode. On vacation this week so it'll be a little bit.

This is a much more GCE specific change for hypervisor detection. Works on arm64 and amd64 VM types.

Well drat. Thanks for the example of hardware that does that. The AArch64 exception model doc I read suggested that wasn't the accepted practice and I was hoping to find something more general than a giant stack of magic strings in identify_hypervisor_smbios. I'll abandon this approach and come back with the patch to smbios_subr.c after I've had a chance to test it.

I don't think moving vfp_save_state(td) is sufficient because of lazy SVE restoration. If the thread hasn't executed SVE instructions since a context switch, the trap to re-enable the unit won't have fired. In that state, vfp_save_state(td) sees the unit as disabled and won't set PCB_FP_SVEVALID and we'll still potentially see this panic. Checking pcb_svesaved != NULL avoids this by checking the backing store directly.