From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42291) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWOum-0000ey-HE for qemu-devel@nongnu.org; Tue, 14 Jun 2011 04:24:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QWOuk-0003R4-Lb for qemu-devel@nongnu.org; Tue, 14 Jun 2011 04:24:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33528) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWOuk-0003QY-4Y for qemu-devel@nongnu.org; Tue, 14 Jun 2011 04:23:58 -0400 Message-ID: <4DF71A97.8090407@redhat.com> Date: Tue, 14 Jun 2011 11:23:51 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4DF33413.9070605@web.de> <4DF5CE2E.50008@redhat.com> <4DF6FB62.60705@web.de> In-Reply-To: <4DF6FB62.60705@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH][uq/master] kvm: x86: Save/restore FPU OP, IP and DP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Christophe Fergeau , Marcelo Tosatti , qemu-devel , kvm , Stefan Hajnoczi On 06/14/2011 09:10 AM, Jan Kiszka wrote: > On 2011-06-13 10:45, Avi Kivity wrote: > > On 06/11/2011 12:23 PM, Jan Kiszka wrote: > >> From: Jan Kiszka > >> > >> These FPU states are properly maintained by KVM but not yet by TCG. So > >> far we unconditionally set them to 0 in the guest which may cause > >> state corruptions - not only during migration. > >> > >> > >> -#define CPU_SAVE_VERSION 12 > >> +#define CPU_SAVE_VERSION 13 > >> > > > > Incrementing the version number seems excessive - I can't imagine a > > real-life guest will break due to fp pointer corruption > > > > However, I don't think we have a mechanism for optional state. We > > discussed this during the 18th VMState Subsection Symposium and IIRC > > agreed to re-raise the issue when we encountered it, which appears to be > > now. > > > > Whatever we invent, it has to be backported as well to allow that > infamous traveling back in time, migrating VMs from newer to older versions. > > Would that backporting be simpler if we used an unconditional subsection > for the additional states? Most likely. It depends on what mechanism we use. Let's spend some time to think about what it would be like. This patch is not urgent, is it? (i.e. it was discovered by code inspection, not live migration that caught the cpu between an instruction that caused a math exception and the exception handler). -- error compiling committee.c: too many arguments to function