qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]