From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH][uq/master] kvm: x86: Save/restore FPU OP, IP and DP Date: Wed, 15 Jun 2011 14:26:16 +0300 Message-ID: <4DF896D8.2000506@redhat.com> References: <4DF33413.9070605@web.de> <4DF5CE2E.50008@redhat.com> <4DF6FB62.60705@web.de> <4DF87717.9090007@redhat.com> <4DF88773.3050401@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm , qemu-devel , Stefan Hajnoczi , Christophe Fergeau To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:4149 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751334Ab1FOL0d (ORCPT ); Wed, 15 Jun 2011 07:26:33 -0400 In-Reply-To: <4DF88773.3050401@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 06/15/2011 01:20 PM, Jan Kiszka wrote: > > > > So fopcode will usually be clear. > > > > OK. So if bit 2 of IA32_MISC_ENABLE MSR, we must save that fields. But > if it's off, how to test for that other condition "last non-transparent > FP instruction ... had an unmasked exception" from the host? > We save fopcode unconditionally. But if IA32_MISC_ENABLE_MSR[2]=0, then fopcode will be zero, and we can skip the subsection (if the data and instruction pointers are also zero, which they will be). If it isn't zero, there's still a good chance fopcode will be zero (64-bit userspace, thread that hasn't used the fpu since the last context switch, last opcode happened to be zero). -- error compiling committee.c: too many arguments to function