[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/2] i386/kvm: lower requirements for Hyper-V fr
From: |
Vitaly Kuznetsov |
Subject: |
Re: [Qemu-devel] [PATCH 2/2] i386/kvm: lower requirements for Hyper-V frequency MSRs exposure |
Date: |
Fri, 16 Mar 2018 16:40:06 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
Paolo Bonzini <address@hidden> 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
[Qemu-devel] [PATCH 1/2] i386/kvm: add support for Hyper-V reenlightenment MSRs, Vitaly Kuznetsov, 2018/03/12