On Mon, Dec 14, 2009 at 02:54:49PM -0600, Anthony Liguori wrote: > 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.
Not emulating feature host CPU does not have is a kernel bug? Okay ... Yes, almost no one runs 2.6.32 yet. >>> 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
