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. -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html