2016-08-01 23:01 GMT+08:00 Paolo Bonzini <pbonzini@xxxxxxxxxx>: > > > On 31/07/2016 04:32, Wanpeng Li wrote: >> 2016-07-14 16:09 GMT+08:00 Paolo Bonzini <pbonzini@xxxxxxxxxx>: >> [...] >>> >>> This is not necessary because this is how KVM computes >>> CPUID[EAX=7,EBX=0].ECX: >>> >>> unsigned f_umip = kvm_x86_ops->umip_emulated() ? F(UMIP) : 0; >>> ... >>> const u32 kvm_cpuid_7_0_ecx_x86_features = F(PKU) | F(UMIP); >>> ... >>> // Mask userspace-provided value against supported features >>> entry->ecx &= kvm_cpuid_7_0_ecx_x86_features; >>> // Mask userspace-provided value against host features >>> cpuid_mask(&entry->ecx, CPUID_7_ECX); >>> // Finally add emulated features >>> entry->ecx |= f_umip; >> >> I think you mean: >> >> - entry->ecx -> userspace-provided value >> - kvm_cpuid_7_0_ecx_x86_features -> supported features >> - CPUID_7_ECX -> host features >> >> However, entry->ecx is returned by cpuid instruction >> (do_cpuid_1_ent()), so why it is a userspace-provided value? > > You're right, it's this: > > // Mask host processor value against supported features > entry->ecx &= kvm_cpuid_7_0_ecx_x86_features; > // Mask host processor value further, e.g. to drop > // features that the host kernel has blacklisted. > cpuid_mask(&entry->ecx, CPUID_7_ECX); > // Finally add emulated features > entry->ecx |= f_umip; > Cool, more clear this time. :) > The idea is the same. :) > > On the other hand, it is true that in many cases of the "switch > (function)" the call to do_cpuid_1_ent is unnecessary, and instead of > cpuid_mask you could just access boot_cpu_data.x86_capability[wordnum]. Agreed. Regards, Wanpeng Li -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
