From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1JtZy1-0007SZ-JR
	for qemu-devel@nongnu.org; Tue, 06 May 2008 23:05:17 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1JtZxz-0007SN-Ml
	for qemu-devel@nongnu.org; Tue, 06 May 2008 23:05:16 -0400
Received: from [199.232.76.173] (port=56955 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1JtZxz-0007SK-H5
	for qemu-devel@nongnu.org; Tue, 06 May 2008 23:05:15 -0400
Received: from wf-out-1314.google.com ([209.85.200.169])
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <mulyadi.santosa@gmail.com>) id 1JtZxy-0006AE-Tu
	for qemu-devel@nongnu.org; Tue, 06 May 2008 23:05:15 -0400
Received: by wf-out-1314.google.com with SMTP id 27so91654wfd.4
	for <qemu-devel@nongnu.org>; Tue, 06 May 2008 20:05:13 -0700 (PDT)
Message-ID: <f284c33d0805062005w1b66405w6485d85a06bfd084@mail.gmail.com>
Date: Wed, 7 May 2008 10:05:13 +0700
From: "Mulyadi Santosa" <mulyadi.santosa@gmail.com>
Subject: Re: [Qemu-devel] FreeBSD/amd64 guests with -kernel-kqemu,
	pagefault at mov %r10d, %gs
In-Reply-To: <20080506185911.GA23589@saturn.kn-bremen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20080506185911.GA23589@saturn.kn-bremen.de>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Hi...

On Wed, May 7, 2008 at 1:59 AM, Juergen Lock <nox@jelal.kn-bremen.de> 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...

But may I ask, what does the effect of "cli" in -kernel-kqemu on
FreeBSD's kqemu?

regards,

Mulyadi.