On Mon, Jul 24, 2017 at 4:23 PM, Radim Krčmář <rkrcmar@xxxxxxxxxx> wrote: > I missed this patch last week, sorry. > > 2017-07-17 15:28+0200, Ladi Prosek: >> It has been experimentally confirmed that supporting these two MSRs is one >> of the necessary conditions for nested Hyper-V to use the TSC page. Modern >> Windows guests are noticeably slower when they fall back to reading >> timestamps from the HV_X64_MSR_TIME_REF_COUNT MSR instead of using the TSC >> page. >> >> The newly supported MSRs are advertised with the AccessFrequencyRegs >> partition privilege flag and CPUID.40000003H:EDX[8] "Support for >> determining timer frequencies is available" (both outside of the scope of >> this KVM patch). > > Do Windows ignore the AccessFrequencyMsrs (CPUID.40000003H:EAX[11]) bit? No, Windows won't read the MSRs without CPUID.40000003H:EAX[11]. The other bit (CPUID.40000003H:EDX[8]) appears to be ignored, or at least I couldn't find any difference in behavior. I wonder why you're asking, i.e. what is it that I'm misunderstanding :) >> Hypervisor Top Level Functional Specification version 5.0b does not >> explicitly mark these MSRs as partition wide. This is, however, implied by >> the way Windows uses them (one read on Hyper-V startup regardless of the >> number of VCPUs) as well as our implementation. >> >> Signed-off-by: Ladi Prosek <lprosek@xxxxxxxxxx> >> --- >> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c >> @@ -1065,6 +1067,12 @@ static int kvm_hv_get_msr_pw(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata) >> case HV_X64_MSR_REFERENCE_TSC: >> data = hv->hv_tsc_page; >> break; >> + case HV_X64_MSR_TSC_FREQUENCY: >> + data = (u64)tsc_khz * 1000; >> + break; > > This should be based on vcpu->arch.virtual_tsc_khz, because KVM can use > guest TSC scaling, Ah, of course. Thanks! > thanks. > >> + case HV_X64_MSR_APIC_FREQUENCY: >> + data = APIC_BUS_FREQUENCY; >> + break; >> case HV_X64_MSR_CRASH_P0 ... HV_X64_MSR_CRASH_P4: >> return kvm_hv_msr_get_crash_data(vcpu, >> msr - HV_X64_MSR_CRASH_P0,
