On Fri, Jun 26, 2009 at 02:42:17AM +0200, Andrea Arcangeli wrote: > that purely asks for troubles I think. At the same time I doubt we > want to deviate much from qemu code here, this seems messy enough > already without big changes to maintain in this area, and I guess this > explains why kvm is only flipping the vendor_id right now... Basically it seems athlon and other cpu definitions are tuned for cpus having vmx/svm and running in legacy mode, that always support sep in legacy mode and always supports syscall in long mode, so while qemu seem to be cheating and not really emulating real hardware, those are good tradeoffs definitions for KVM and it explains why it's enough to flip the vendor_id to match the host vendor_id to get compatibility mode right on 64bit guests, but only as long as 6/3/3 is set (hence the reason of the patch). So in short, we can't make any further change in KVM in addition to waiting the common denominator to move to 6/3/3. First qemu has to decide if it goes ahead not emulating real 32bit athlon but by providing feature flags definition of a svm/vmx cpu in legacy mode. -- 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
