Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

[Anthony Liguori]

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