From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MRNuY-0003R7-15 for qemu-devel@nongnu.org; Thu, 16 Jul 2009 06:09:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MRNuT-0003PV-Ly for qemu-devel@nongnu.org; Thu, 16 Jul 2009 06:09:57 -0400 Received: from [199.232.76.173] (port=48443 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRNuT-0003PQ-Fq for qemu-devel@nongnu.org; Thu, 16 Jul 2009 06:09:53 -0400 Received: from outbound-dub.frontbridge.com ([213.199.154.16]:53360 helo=IE1EHSOBE005.bigfish.com) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.60) (envelope-from ) id 1MRNuS-0004N6-Tn for qemu-devel@nongnu.org; Thu, 16 Jul 2009 06:09:53 -0400 Message-ID: <4A5EFC47.3050304@amd.com> Date: Thu, 16 Jul 2009 12:09:11 +0200 From: Andre Przywara MIME-Version: 1.0 Subject: Re: [Qemu-devel] CPUID feature bits not saved with migration References: <4A5DD0B0.7070700@amd.com> <4A5DE9E5.2080809@codemonkey.ws> <20090715151234.GA28724@shareable.org> <4A5ECEE9.8070708@redhat.com> In-Reply-To: <4A5ECEE9.8070708@redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dlaor@redhat.com Cc: qemu-devel@nongnu.org Dor Laor wrote: > On 07/15/2009 06:12 PM, Jamie Lokier wrote: >> Anthony Liguori wrote: >>> It's unclear what to do about -cpu host. If we did migrate cpuid >>> values, then -cpu would effectively be ignored after an incoming >>> migration. > > Actually, it might be better to build all of the guest configurations > (devices, cpu, etc) from the migration stream, without stating them in > the destination command line. > > The destination command line should only contain host configuration. > It will bypass any type of conflict between the src/dst pairs. I think there were some ideas on implementing this (transfer of guest configuration in a separate savevm section) in the past. Has someone started looking at this? >> >> The new host might not support all the cpuid features of the old host, >> whether by -cpu host or explicit cpuid. What happens then? >> >> For changing cpuid when migrating, as you might like to do with -cpu >> host for performance, is reboot-during-migrate useful? It would make >> sure all disk state is committed to the image files asynchronously >> while the machine continues to run (just like normal migration), and >> at the last moment transfers control and the machine sees a reboot, >> permitting devices changes including cpuid change. >> >> CPU hotplug could be used for cpuid change in theory, but I doubt if >> any guests or guest apps would handle it well. > > We should just fail migration in case the destination host cannot match > the source requirements (cpuid, cpu vendor type (optionally emulate > them), etc). > The complexity does not worth the gain and it won't be common practice. For items not efficiently emulate-able (like SSE4) I agree. But I would try to make this list as short as possible. For instance I have an idea on how to cope with missing host's NX/XD capability, so one does not need to dump this feature because there is a single incapable box in the migration pool. Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 448 3567 12 ----to satisfy European Law for business letters: Advanced Micro Devices GmbH Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen Geschaeftsfuehrer: Thomas M. McCoy; Giuliano Meroni Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632