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 ‘kvm_get_xsave’: > /home/ykaul/qemu/target-i386/kvm.c:953:29: error: variable ‘fop’ set but > not used [-Werror=unused-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 information 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 handle it, because likely qemu tcg never emulated it and thus we never had anywhere to stow it.
To trigger a bug here you'd need a live migration that happens after an x87 fpu instruction that causes an exception but before the next fpu instruction (which would trigger an exception), plus an exception handler that reads this information (I think Linux doesn't), plus an 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. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
