"[Firmware Bug]: TSC doesn't count with P0 frequency!"

@jordanhendricks noticed this in the logs of a Linux instance booting. it looks to me like this is a probably-harmless oversight in the MSRs propolis doesn't yet properly support. from Linux there,

[    0.000000] Linux version 6.18.9-talos (root@buildkitsandbox) (gcc (GCC) 15.2.0, GNU ld (GNU Binutils) 2.45.1) #1 SMP Thu Feb 12 11:50:06 UTC 2026
[    0.000000] Command line: talos.platform=nocloud net.ifnames=0 init_on_alloc=1 slab_nomerge pti=on consoleblank=0 nvme_core.io_timeout=4294967295 printk.devkmsg=on selinux=1 module.sig_enforce=1 console=ttyS0
[    0.000000] [Firmware Bug]: TSC doesn't count with P0 frequency!

this comes from this bit of Linux:

static void bsp_init_amd(struct cpuinfo_x86 *c)
{
	if (cpu_has(c, X86_FEATURE_CONSTANT_TSC)) {

		if (c->x86 > 0x10 ||
		    (c->x86 == 0x10 && c->x86_model >= 0x2)) {
			u64 val;

			rdmsrq(MSR_K7_HWCR, val);
			if (!(val & BIT(24)))
				pr_warn(FW_BUG "TSC doesn't count with P0 frequency!\n");
		}
	}

and in propolis-standalone you even get the Unhandled rdmsr 0xc0010015, rip: ... line pretty early on in boot. I'm pretty sure we return 0 for the unhandled read in server and standalone, which is consistent with bit 24 being unset and Linux warning.

in practice I'm pretty sure this bit has been set on every AMD CPU that reports a constant TSC in CPUID (I'm curious what motivated the MSR read here over in Linux in fact...), and in reality the TSC quite surely does count with P0 on hardware we're testing on. we probably should just set this bit in K7_HWCR? I don't see anywhere that Linux at least would ever notice it being set later on though.

Start by locating the K7_HWCR/MSR handling in propolis-server and propolis-standalone, then inspect how unhandled reads are returned. Reproduce the Linux boot warning and verify that handling bit 24 of MSR_K7_HWCR removes the warning without changing other guest behavior.