@@ -315,6 +315,13 @@ int guest_rdmsr(struct vcpu *v, uint32_t
*val = msrs->tsc_aux;
break;
+ case MSR_K8_HWCR:
+ if ( !(cp->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) )
+ goto gp_fault;
+ *val = get_cpu_family(cp->basic.raw_fms, NULL, NULL) >= 0x10
+ ? K8_HWCR_TSC_FREQ_SEL : 0;
+ break;
+
case MSR_AMD64_DE_CFG:
if ( !(cp->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) )
goto gp_fault;
@@ -287,6 +287,8 @@
#define MSR_K7_HWCR 0xc0010015
#define MSR_K8_HWCR 0xc0010015
+#define K8_HWCR_TSC_FREQ_SEL (1ULL << 24)
+
#define MSR_K7_FID_VID_CTL 0xc0010041
#define MSR_K7_FID_VID_STATUS 0xc0010042
#define MSR_K8_PSTATE_LIMIT 0xc0010061
Linux has been warning ("firmware bug") about this bit being clear for a long time. While writable in older hardware it has been readonly on more than just most recent hardware. For simplicitly report it always set (if anything we may want to log the issue ourselves if it turns out to be clear on older hardware) on CPU families 10h and up (in family 0fh the bit is part of a larger field of different purpose). Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> --- v3: Report 0 for Fam0F. v2: New. --- There are likely more bits worthwhile to expose, but for about every one of them there would be the risk of a lengthy discussion, as there are clear downsides to exposing such information. The more that it would be tbd whether the hardware values should be surfaced, and if so what should happen when the guest gets migrated. The main risk with making the read not fault here is that guests might imply they can also write this MSR then.