From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:44592)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1QWoKc-0001EI-7J
	for qemu-devel@nongnu.org; Wed, 15 Jun 2011 07:32:23 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1QWoKa-0004g4-IQ
	for qemu-devel@nongnu.org; Wed, 15 Jun 2011 07:32:22 -0400
Received: from david.siemens.de ([192.35.17.14]:16257)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1QWoKZ-0004ei-Tc
	for qemu-devel@nongnu.org; Wed, 15 Jun 2011 07:32:20 -0400
Message-ID: <4DF8983B.5020009@siemens.com>
Date: Wed, 15 Jun 2011 13:32:11 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
MIME-Version: 1.0
References: <4DF33413.9070605@web.de> <4DF5CE2E.50008@redhat.com>
	<4DF6FB62.60705@web.de> <4DF87717.9090007@redhat.com>
	<4DF88773.3050401@web.de> <4DF896D8.2000506@redhat.com>
In-Reply-To: <4DF896D8.2000506@redhat.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH][uq/master] kvm: x86: Save/restore FPU OP,
	IP and DP
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: Christophe Fergeau <cfergeau@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>, qemu-devel <qemu-devel@nongnu.org>, kvm <kvm@vger.kernel.org>, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>

On 2011-06-15 13:26, Avi Kivity wrote:
> 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).

I do not yet find "if fopcode is invalid, it is zero, just as IP and DP"
in the spec. What clears them reliably?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux