|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] cpuid problem in upstream qemu with kvm |
Date: | Sun, 20 Dec 2009 11:49:40 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 |
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.
-- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |