From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM Processor cache size Date: Tue, 03 Aug 2010 08:38:38 +0300 Message-ID: <4C57AB5E.1070904@redhat.com> References: <4C56BF6F.9040402@amd.com> <4C56C353.7020607@redhat.com> <4C574512.6030903@codemonkey.ws> <4C574845.8060906@amd.com> <4C5756F0.6040205@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andre Przywara , Ricardo Martins , "kvm@vger.kernel.org" To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:3562 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754720Ab0HCFit (ORCPT ); Tue, 3 Aug 2010 01:38:49 -0400 In-Reply-To: <4C5756F0.6040205@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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.