Re: KVM Processor cache size

[Anthony Liguori <anthony@codemonkey.ws>]

On 08/02/2010 05:35 PM, Andre Przywara wrote:
> Anthony Liguori wrote:
>> On 08/02/2010 08:08 AM, Avi Kivity wrote:
>>>> I sent a patch to include the cache size when using -cpu host, but 
>>>> this has been n'acked because the benefit is not clear.
>>>
>>> Anthony, why was this NACKed?
>>
>> I didn't NACK it.
> You are right. I am sorry if that created a misunderstanding, I 
> actually meant: "was not committed".
>>
>> My concern is that we're still not handling live migration with -cpu 
>> host in any meaningful way.  Exposing more details without addressing 
>> live migration is going to increase the likelihood of major failure.
> Would you accept a patch simply disabling migration in case -cpu host 
> was used in the first place?

Yes.  The only concern that keeps me from applying it is that it 
increases the likelihood of failures with migration.  I agree that it's 
safer to disable migration until it's fixed properly.

>>
>> We need to add cpuid information to live migration such that we can 
>> generate a graceful failure during migration.  Really, we shouldn't 
>> have taken -cpu host in the first place without this.
> Is there already a way to communicate from the target to the source? 
> This would allow to check for migrate-ability before we transfer any 
> data. Or should we handle this in a management application?

Send the cpuid fields as part of migration state.  Verify they match the 
local cpuid fields on the destination side.  The destination can then 
reject the migration if it can't match those CPUID fields.  That's 
actually the only way to safely do it today because there's no way for a 
management application to query qemu and kvm for the fields that they'll 
mask out.

Regards,

Anthony Liguori

> Regards,
> Andre.
>