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

[Michael S. Tsirkin]

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