On Sun, Dec 20, 2009 at 11:49:40AM +0200, Avi Kivity wrote: > On 12/14/2009 10:18 PM, Anthony Liguori wrote: >> Michael S. Tsirkin wrote: >>> This might help 32 bit guests, but not guests with 64 bit >>> kernel and 32 bit userspace (my case) because all 64 bit >>> CPUs advertise syscall bit in cpuid. Thus 64 bit guests >>> do not seem to even bother checking this bit: >>> AMD + 64 bit -> syscall. >> >> Okay, I don't see a great option other than migrating the vendor_id >> string. >> > > That's not strictly necessary since the guest cannot change the vendor > string; all the user has to do is to launch both guests with explicit > vendor ids. Of course that imposes more on the user (or the management > application). > >> Otherwise, cross vendor migration will not work by default. Maybe >> that's not a problem but if so, we really should change the default >> cpu model to be much more aggressive about exposing host features. > > Maybe we should make -cpu host the default. That will give the best > performance for casual users, more testing for newer features, and will > force management apps to treat migration much more seriously. The > downside is that casual users upgrading their machines might experience > issues with Windows. Feature compatibility is not just about migration.
This seems very aggressive. Can't we whitelist features that we know about? Further, doesn't KVM already do this? -- MST
