On Jul 27, 2018, at 1:28 PM, Jim Mattson jmattson@google.com wrote:
On Fri, Jul 27, 2018 at 12:41 PM, Andy Lutomirski luto@kernel.org wrote:
On Wed, Feb 8, 2017 at 12:09 AM, Kyle Huey me@kylehuey.com wrote: Hardware support for faulting on the cpuid instruction is not required to emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant MSRs (MSR_PLATFORM_INFO and MSR_MISC_FEATURES_ENABLE) and upon a cpuid-induced VM exit checks the cpuid faulting state and the CPL. kvm_require_cpl is even kind enough to inject the GP fault for us.
Signed-off-by: Kyle Huey khuey@kylehuey.com Reviewed-by: David Matlack dmatlack@google.com
... @@ -7613,16 +7636,19 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
kvm_clear_async_pf_completion_queue(vcpu); kvm_async_pf_hash_reset(vcpu); vcpu->arch.apf.halted = false; if (!init_event) { kvm_pmu_reset(vcpu); vcpu->arch.smbase = 0x30000;
vcpu->arch.msr_platform_info = MSR_PLATFORM_INFO_CPUID_FAULT;vcpu->arch.msr_misc_features_enables = 0;Jim, I assume you're worried about this bit? It seems like msr_platform_info should maybe be initialized to zero to avoid causing an unintended migration issue.
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
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?-- 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