lkml.org 
[lkml]   [2018]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v14 8/9] KVM: x86: virtualize cpuid faulting
On Fri, Jul 27, 2018 at 2:03 PM, Jim Mattson <jmattson@google.com> wrote:
> On Fri, Jul 27, 2018 at 1:46 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> On Jul 27, 2018, at 1:28 PM, Jim Mattson <jmattson@google.com> 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’t have a good answer to that. Are there any real CPUs that have this MSR but don’t 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.

\
 
 \ /
  Last update: 2018-07-27 23:07    [W:0.036 / U:1.892 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site