From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: =?windows-1252?Q?Re=3A_Failure_to_compile_latest_git_?=
 =?windows-1252?Q?=28target-i386/kvm=2Ec=3A953=3A29=3A_error=3A_varia?=
 =?windows-1252?Q?ble_=91fop=92_set_but_not_used=29?=
Date: Sun, 24 Apr 2011 10:10:17 +0300
Message-ID: <4DB3CCD9.6020602@redhat.com>
References: <4DB03AC4.1070907@redhat.com> <4DB05086.7050609@siemens.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252;
	format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Yaniv Kaul <ykaul@redhat.com>, qemu-devel@nongnu.org,
	kvm <kvm@vger.kernel.org>
To: Jan Kiszka <jan.kiszka@siemens.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:5553 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754396Ab1DXHK0 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sun, 24 Apr 2011 03:10:26 -0400
In-Reply-To: <4DB05086.7050609@siemens.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 04/21/2011 06:43 PM, Jan Kiszka wrote:
> On 2011-04-21 16:10, Yaniv Kaul wrote:
> >  Fedora 15beta/x64, latest git:
> >  [ykaul@ykaul qemu]$ make
> >    CC    x86_64-softmmu/kvm.o
> >  /home/ykaul/qemu/target-i386/kvm.c: In function =91kvm_get_xsave=92=
:
> >  /home/ykaul/qemu/target-i386/kvm.c:953:29: error: variable =91fop=92=
 set but
> >  not used [-Werror=3Dunused-but-set-variable]
> >  cc1: all warnings being treated as errors
> >
> >  make[1]: *** [kvm.o] Error 1
> >  make: *** [subdir-x86_64-softmmu] Error 2
> >
>
> This one looks a bit suspicious:
>
> Avi, why do we have kvm_fpu::last_* in the ABI, copying that informat=
ion
> from/to user land, but do not handle it otherwise?

We have in in the ABI because it is part of the FPU state.  We don't=20
handle it, because likely qemu tcg never emulated it and thus we never=20
had anywhere to stow it.

To trigger a bug here you'd need a live migration that happens after an=
=20
x87 fpu instruction that causes an exception but before the next fpu=20
instruction (which would trigger an exception), plus an exception=20
handler that reads this information (I think Linux doesn't), plus an=20
application that cares about the data...

Note the kernel does handle it correctly.

> To my understanding
> this fop here in xsave corresponds to kvm_fpu::last_opcode in the
> SET/GET_FPU case, right? It's set to 0 on SET_XSAVE and ignored on
> GET_XSAVE as this warnings tells us.

We have exactly the same issue in kvm_get_fpu(), just with no warning.

--=20
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.