Dong, Eddie wrote: > Avi/Anthony: > Following commit added #UD trap in KVM and do emulation in KVM. > It is good to avoid the mis hypercall instruction issue, but I am not > sure if it will have any serious side effect. I am blind to AMD > instruction, I assume, for example, AMD 3D now instruction may use > different binary and thus invalid_ops in Intel platform. If an > application with 3D now instructions is executed in Intel platform, now > KVM get #UD and may do emulation inside, will that cause problem rather > then we inject #UD to guest? If this suspicion is true, then probably we > need to do something more to this commitment, i.e. to emulate > cross-architecturally VMCALL instruction only for this purpose. > >
Since we don't emulate 3Dnow instructions, a #UD will be injected instead. The plan for having mixed vendor migration is to disable such extensions in cpuid, so the guest won't even try to execute them. In other words, the cpuid in a virtualization farm will be set to the greatest common subset of cpu features. > BTW, do we need to support live migrating an AMD VM to Intel platform or > vice versa Yes, it allows users to buy the machines with the best cost/performance ratio, rather than continue to buy machines from the same vendor all the time. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
