[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] FreeBSD/amd64 guests with -kernel-kqemu, pagefault at m
From: |
Juergen Lock |
Subject: |
Re: [Qemu-devel] FreeBSD/amd64 guests with -kernel-kqemu, pagefault at mov %r10d, %gs |
Date: |
Fri, 9 May 2008 23:20:55 +0200 (CEST) |
In article <address@hidden> you write:
>Hi...
>
>On Wed, May 7, 2008 at 1:59 AM, Juergen Lock <address@hidden> wrote:
>> ..before that it does a mov %r10d,%fs which seems to work (%r10d is
>> _udatasel in both cases) so it can't be the segment itself that it
>> doesn't like, or can it? Anyone have an idea what this might be?
>> (it works without -kernel-kqemu.)
>
><..snip..>
>
>> 0xffffffff806dc752 <exec_setregs+98>: mov 4183943(%rip),%r10d
># 0xffffffff80ad9ee0 <_udatasel>
>> 0xffffffff806dc759 <exec_setregs+105>: mov %r10d,%ds
>> 0xffffffff806dc75c <exec_setregs+108>: mov %r10d,%es
>> 0xffffffff806dc75f <exec_setregs+111>: mov %ebx,%ecx
>> 0xffffffff806dc761 <exec_setregs+113>: rdmsr
>> 0xffffffff806dc763 <exec_setregs+115>: mov %r10d,%fs
>> 0xffffffff806dc766 <exec_setregs+118>: wrmsr
>> 0xffffffff806dc768 <exec_setregs+120>: mov $0xc0000101,%ecx
>> 0xffffffff806dc76d <exec_setregs+125>: pushfq
>> 0xffffffff806dc76e <exec_setregs+126>: cli
>> 0xffffffff806dc76f <exec_setregs+127>: rdmsr
>> 0xffffffff806dc771 <exec_setregs+129>: mov %r10d,%gs
>> failed insn ^^^^^^^^^^^^^^^^^^
>
>I think I agree somehow accessing %gs is the quirk. let's just hope gs
>points to valid entry in GDT or LDT...
>
As I said %r10d is _udatasel here and was just succesfully loaded into %fs.
>But may I ask, what does the effect of "cli" in -kernel-kqemu on
>FreeBSD's kqemu?
>
cli seems to be handled in kqemu-1.3.0pre11/common/interp.c in
insn_interp(), look for
LABEL(fa) /* cli */
Or do you mean why cli is used here? %gs is used for cpu-local
variables in the FreeBSD kernel (like curthread), and since the gsbase
msr apparently gets reset on a mov to %gs, it needs to be saved and
restored across that mov, and cli is then needed because an interrupt
that would be executed before the msr is restored would find cpu-local
variables wrong...
Oh, and just in case this is not clear, this is code from the guest not
from kqemu itself. :)
Juergen