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

[Anthony Liguori <anthony@codemonkey.ws>]

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