On Thu, Apr 11, 2013 at 05:37:33PM +0200, Borislav Petkov wrote: > On Thu, Apr 11, 2013 at 05:28:18PM +0300, Gleb Natapov wrote: > > On Thu, Apr 11, 2013 at 02:18:15AM +0200, Borislav Petkov wrote: > > > On Wed, Apr 10, 2013 at 03:16:39PM +0300, Gleb Natapov wrote: > > > > Right, the question is how kernel can tell QEMU that the cpuid bit is > > > > supported but should not be set unless explicitly asked by an user. > > > > > > Actually, this seems to work with the patch below based on whether you > > > have "+movbe" in the -cpu option or not. > > > > > The problem is that -cpu host will have it unconditionally and this is > > definitely not what we want. > > Hmm, ok, I see what you mean. -cpu host boots the atom kernel just fine. > > Well, with my limited qemu exposure, I'd guess > cpu_x86_parse_featurestr() would need to somehow say to > x86_cpu_realizefn that it has parsed a "+movbe" on the command line and > the latter has to keep that bit enabled when doing the checks against > kvm in kvm_check_features_against_host and filter_features_for_kvm(). > Then you will filter out movbe even if host cpu supports it directly which is also not what we want. Currently userspace assumes that that cpuid configuration returned by KVM_GET_SUPPORTED_CPUID is the optimal one. What we want here is a way for KVM to tell userspace that it can emulate movbe though it is not optimal. Userspace alone cannot figure it out. It can check host's cpuid directly and assume that if cpuid bit is not present on the host cpu, but reported as supported by KVM then it is emulated by KVM and this is not optimal, but sometimes emulation is actually desirable (x2apic), so such assumption is not always correct. -- Gleb. -- 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
