Paolo Bonzini <[email protected]> writes: > On 20/03/2018 18:35, Vitaly Kuznetsov wrote: >> + if (has_msr_hv_frequencies && env->tsc_khz) { >> env->features[FEAT_HYPERV_EAX] |= HV_ACCESS_FREQUENCY_MSRS; >> env->features[FEAT_HYPERV_EDX] |= HV_FREQUENCY_MSRS_AVAILABLE; >> } > > Since you have added cpu->hyperv_reenlightenment, I'd rather change this > so that we don't make the "license to change guest ABI across migration" > apply more. We can exploit the fact that Windows doesn't even use the > MSRs unless either invtsc or re-enlightenment is present. Something > like this: > > if (has_msr_hv_frequencies && env->tsc_khz && > (tsc_is_stable_and_known(env) || > cpu->hyperv_reenlightenment)) > > will make the MSRs visible in all useful cases, without having to add > yet another knob. >
Can be arranged, of course. (What I'm worried about with all our hv_* knobs is that more of them we have easier it is to assemble some frankenstien which won't look like any existing Hyper-V version; we're probably not doing a very good job tesing all possible hv_* combinations as people probably use 'all or nothing'. In case we end up finding a bug in Windows with some weird hv_* combination it's unlikely Microsoft will bother fixing at as it doesn't reproduce on any existent Hyper-V version. That said, it would be great to eventually have something like 'hv_ws2012r2' property making us look exactly the same real WS2012R2 looks like. Unfortunatelly, I'm unsure about a path to get there). > (Don't worry, this backwards-compatibility stuff is the hardest part. > I'm so happy that Eduardo is the one maintaining it :)). I feel the pain :-) Thanks for the reviews! -- Vitaly
