From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mf8zF-0001Ni-DT for qemu-devel@nongnu.org; Sun, 23 Aug 2009 05:03:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mf8zA-0001NP-FG for qemu-devel@nongnu.org; Sun, 23 Aug 2009 05:03:41 -0400 Received: from [199.232.76.173] (port=60915 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mf8zA-0001NM-90 for qemu-devel@nongnu.org; Sun, 23 Aug 2009 05:03:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59754) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mf8z9-0004vy-Ko for qemu-devel@nongnu.org; Sun, 23 Aug 2009 05:03:35 -0400 Message-ID: <4A9105DF.4090504@redhat.com> Date: Sun, 23 Aug 2009 12:03:27 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1250804057-29681-1-git-send-email-andre.przywara@amd.com> <4A8EC03D.4000202@redhat.com> <5d6222a80908210901n127ec497hb858225021921495@mail.gmail.com> <4A8F1765.6060306@amd.com> In-Reply-To: <4A8F1765.6060306@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] introduce kvm64 CPU List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andre Przywara Cc: Glauber Costa , qemu-devel@nongnu.org, kvm@vger.kernel.org On 08/22/2009 12:53 AM, Andre Przywara wrote: >>> I think this is best left to management software, which has more >>> information >>> about the migration pool. >> I believe what we want is an automatic tool that will connect to a >> list of machines,and determine which qemu cpu type we should use. > > > Doesn't sound like black magic... > I already have such a basic tool. It uses ssh (with pubkey) to connect > to the target machine, then uses dd on /dev/cpu/0/cpuid to get the > CPUID info. This requires cpuid.ko to be loaded and the permissions on > the device file to be sufficient (the appropriate udev patch is > already upstream). It then computes the least common denominator bits > from several machines. > Were you thinking of that approach or do you want to include this host > CPUID functionality into QEMU (somehow embedded in the migration > handler)? When qemu is involved it is already far too late. This node needs to be classified when it is added to the cluster. But maybe we can integrate it into 'qemu -capabilities', if and when that is added. -- error compiling committee.c: too many arguments to function