Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 02:18:33PM -0600, 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.
This won't help with kernels <2.6.32 though. I guess we can switch
default vendor to Intel, this likely has some other side effects.
That's a kernel bug. If we think it effects a lot of users, we should
introduce a CAP such that we can detect this in userspace and fail
gracefully.
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.
It's a tradeoff, but yes. We also need more sanity checks and
management commands giving management tools to understand whether
emulating guest CPU X on host CPU Y is safe/possible, and which guests
this might break.
I'd like to see Avi weigh in as historically, he's been one of the
strongest advocates of a default migration policy of maximum
compatibility. Personally, I think cross vendor migration is extremely
uncommon in production and I would strongly recommend against it.
My own experience has been that hardware homogeneity is pretty common in
deployments, particularly in the processor space. There's such a
different between Nehalem and non-Nehalem class processors that you
really can't run the same workloads across the two without seeing a
significant impact.
So I'd actually be in favor of changing the default cpu to something
that exposes a lot more of the underlying processor features. I think
increased performance would be better for most consumers vs. increased
migration flexibility.
Then again, I'm certainly bias based on being employed by a hardware
vendor :-)
Regards,
Anthony Liguori
