amd64/vmm: Don't advertise AMD PerfMonV2 or performance counters

[christos]

Summary

vmm does not handle CPUID leaf 0x80000022, so a FreeBSD guest on a
Family 19h or later host panics on "kldload hwpmc", which trusts the
PerfMonV2 bit and writes AMD_PMC_GLOBAL_CTL.

MFC after: 1 week
Sponsored by: The FreeBSD Foundation

[christos]

@markj I haven't tested this patch yet. If you can spin up a -CURRENT host and try it today please let me know, otherwise I can test it tomorrow.

[markj]

This is fine, but it won't help older versions of FreeBSD which use vmm to boot a newer FreeBSD guest. I think this will still need a workaround in hwpmc, gated on vm_guest == VM_GUEST_BHYVE.

[kib]

In D61141#1401766, @markj wrote:

This is fine, but it won't help older versions of FreeBSD which use vmm to boot a newer FreeBSD guest. I think this will still need a workaround in hwpmc, gated on vm_guest == VM_GUEST_BHYVE.

Well, if we stop trusting the CPUID bits, we will dig very deep hole for ourselves.

[christos]

In D61141#1401766, @markj wrote:

This is fine, but it won't help older versions of FreeBSD which use vmm to boot a newer FreeBSD guest. I think this will still need a workaround in hwpmc, gated on vm_guest == VM_GUEST_BHYVE.

That sounds a bit like a hack though, no? Wouldn't it make more sense to either MFC this (and any other similar patches) the older still-supported versions of FreeBSD, or commit D61133 along with this one?

[markj]

In D61141#1402074, @christos wrote:

In D61141#1401766, @markj wrote:

This is fine, but it won't help older versions of FreeBSD which use vmm to boot a newer FreeBSD guest. I think this will still need a workaround in hwpmc, gated on vm_guest == VM_GUEST_BHYVE.

That sounds a bit like a hack though, no? Wouldn't it make more sense to either MFC this (and any other similar patches) the older still-supported versions of FreeBSD, or commit D61133 along with this one?

It is a hack, but such is life. Certainly this commit should be MFCed to stable/15 and 14 at minimum. I guess, since one needs to load hwpmc.ko to trigger the problem, it's not so likely to annoy users.

[mhorne]

In D61141#1402118, @markj wrote:

In D61141#1402074, @christos wrote:

In D61141#1401766, @markj wrote:

This is fine, but it won't help older versions of FreeBSD which use vmm to boot a newer FreeBSD guest. I think this will still need a workaround in hwpmc, gated on vm_guest == VM_GUEST_BHYVE.

That sounds a bit like a hack though, no? Wouldn't it make more sense to either MFC this (and any other similar patches) the older still-supported versions of FreeBSD, or commit D61133 along with this one?

It is a hack, but such is life. Certainly this commit should be MFCed to stable/15 and 14 at minimum. I guess, since one needs to load hwpmc.ko to trigger the problem, it's not so likely to annoy users.

I agree that the secondary fix/hack to hwpmc is warranted. Please do not gate based on vm_guest, but reopen D61133, as that change looks to be appropriate. amd_hwcheck() is intentionally conservative; it attempts to verify the functionality of the hardware, not necessarily trusting the CPUID feature reporting.

[christos]

In D61141#1402118, @markj wrote:

Certainly this commit should be MFCed to stable/15 and 14 at minimum.

I'll MFC it to stable/14 and 15 after a week, and if you think it should also go in releng, give me the green light and I can do it if you want.

In D61141#1402166, @mhorne wrote:

I agree that the secondary fix/hack to hwpmc is warranted. Please do not gate based on vm_guest, but reopen D61133, as that change looks to be appropriate. amd_hwcheck() is intentionally conservative; it attempts to verify the functionality of the hardware, not necessarily trusting the CPUID feature reporting.

Seconding this.

[ojanerif_amd.com]

Tested on Zen4 host: hot-loaded a vmm.ko built with this patch, booted a guest, confirmed from inside it that CPUID.80000022h now returns all-zero (PerfMonV2 no longer advertised). kldload hwpmc still loads cleanly (exit 0), no panics. (Same prerequisite as the D61133 test: host needed the ASID fix in D61226 to get a bhyve+UEFI guest to boot at all.) LGTM.