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:5.013 / U:0.380 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site