Paolo Bonzini <[email protected]> writes: > On 16/03/2018 16:05, Vitaly Kuznetsov wrote: >>>> >>>> - if (has_msr_hv_frequencies && tsc_is_stable_and_known(env)) { >>>> + if (has_msr_hv_frequencies && env->tsc_khz) { >>> Should this be >>> >>> ((env->tsc_khz && has_msr_hv_reenlightenment) || >>> tsc_is_stable_and_known(env)) >>> >>> so that you don't regress on older kernels? >>> >> I don't actually see where the regression might come from: frequency >> MSRs are supported regardless or reenlightenment/invtsc and there's >> nothing wrong with exposing them but I may be missing something.. > > On older kernel without re-enlightenment support, you don't want to > expose the frequency MSRs unless invtsc is on, right? >
Actually no, I think it's OK to expose frequency MSRs even when we don't have invtsc and don't support re-enlightenment. Nested Hyper-V won't pass stable TSC pages to its guests unless it sees either invtsc or reenlightenment. So as long as we have something to put to these MSRs (env->tsc_khz) I *think* we can expose them. I may actually be missing the reason why Ladi put tsc_is_stable_and_known() here. In case we're running Windows (and not Hyper-V) as a guest KVM will update TSC page on migration. And genuine Hyper-V also exposes these MSRs without exposing INVTSC flag by default. -- Vitaly
