Re: KVM Processor cache size

[Avi Kivity <avi@redhat.com>]

  On 08/03/2010 02:38 AM, Anthony Liguori wrote:
> 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?

Since this is determined at startup time, it should be done by 
management.  There's no point in starting a live migration that we know 
will fail.

>
> 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. 

I agree with that, as a safety check.

Note it can be determined even earlier, if qemu warns/fails on masked 
features:

    qemu -cpu qemu64,+this,-that,strict


> 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.

That needs to part of the qemu capabiltities megapatch.  Supporting 
POPCNT isn't very different from supporting cache=unsafe from the 
management point of view.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.