On 07/05/2010 10:42 AM, Avi Kivity wrote:
Please don't top-post.
On 07/03/2010 05:23 PM, BuraphaLinux Server wrote:
Ok, I kept going like you said. Here is what it said:
$git bisect good
44ea2b1758d88ad822e65b1c4c21ca6164494e27 is the first bad commit
commit 44ea2b1758d88ad822e65b1c4c21ca6164494e27
Author: Avi Kivity<a...@redhat.com>
Date: Sun Sep 6 15:55:37 2009 +0300
KVM: VMX: Move MSR_KERNEL_GS_BASE out of the vmx autoload msr area
Currently MSR_KERNEL_GS_BASE is saved and restored as part of the
guest/host msr reloading. Since we wish to lazy-restore all the
other
msrs, save and reload MSR_KERNEL_GS_BASE explicitly instead of
using
the common code.
Signed-off-by: Avi Kivity<a...@redhat.com>
That doesn't make any sense. This commit shouldn't affect anything in
user-kernel communications.
Can you describe your environment? I'll try to reproduce it.
I was able to reproduce it, and the commit does make sense.
The faulting instruction is
0x807182a <post_kvm_run+10> mov %gs:0x14,%eax
which is a stack guard fetch. It shouldn't ever fault - so it looks
like %gs is corrupted, and indeed the commit plays with %gs.
I'll investigate further.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
