Re: [PATCH v14 8/9] KVM: x86: virtualize cpuid faulting

On Fri, Jul 27, 2018 at 2:03 PM, Jim Mattson <[email protected]> wrote:
> On Fri, Jul 27, 2018 at 1:46 PM, Andy Lutomirski <[email protected]> wr=
ote:
>>> On Jul 27, 2018, at 1:28 PM, Jim Mattson <[email protected]> wrote:
>>> Initializing this bit to zero helps with migration, but then if the
>>> CPUID faulting bits in both MSRs are set, userspace has to take pains
>>> to ensure that MSR_PLATFORM_INFO is restored first, or the
>>> MSR_MISC_FEATURES_ENABLES value will be rejected.
>>
>> The code could drop the constraint and just let the entry possibly fail =
if the MSRs are set wrong
>
> That would be an improvement, I think.

I personally don't know enough about the QEMU, kvmtool, etc
architecture to know whether this would be a good idea.

>
>>> I'm also concerned about the 0 in the "Maximum Non-Turbo Ratio" field
>>> feeding into someone's calculated TSC frequency.
>>
>> Hmm. I don=E2=80=99t have a good answer to that. Are there any real CPUs=
 that have this MSR but don=E2=80=99t have that field?
>
> No. The reason I bring this up is that a customer has code that
> expects to be able to derive the TSC frequency from this MSR (per
> Intel's instructions in SDM volume 3, section 18.7.3), and they were
> surprised to find that the MSR raises #GP on our platform. We're
> looking into cherry-picking this support from upstream as a start, but
> I know the customer would be unhappy to read zero from bits 15:8.

Does KVM *have* a concept of "maximum non-turbo frequency" of the
guest that it would make sense to expose here?  If so, presumably the
right solution is to expose it.