This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] fxsave, fnsave, ltr hang for guest OS.

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] fxsave, fnsave, ltr hang for guest OS.
From: alarson@xxxxxxxx
Date: Fri, 12 Nov 2010 15:27:17 -0600
Delivery-date: Fri, 12 Nov 2010 13:29:41 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C8F894EC.277A7%keir@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
History: fnsave in my 32-bit protected mode OS 'hangs' when paging is
turned on.

Keir Fraser <keir.xen@xxxxxxxxx> wrote on 11/04/2010 11:50:52 AM:

> On 04/11/2010 16:32, "alarson@xxxxxxxx" <alarson@xxxxxxxx> wrote:
AL> ... When I restricted the two clients (dom0 and my os) to
AL> exclusively their own CPU, then, if you exclude the first trace
AL> below, a pattern seems to emerge, and it would seem that I should
AL> start with sh_page_fault().

KF> Hm, well maybe. sh_page_fault() is the entry point to one of the
KF> most complex pieces of the hypervisor, so you're likely to find it
KF> more of a sticky tar pit than a source of salvation. It may be
KF> involved, but you might want to wade in armed with some more debug
KF> info first so that your search has some greater focus.

KF> I would dispense with sampling the 'd' key -- clearly a bunch of
KF> stuff is happening -- and instead go for printk() tracing in the
KF> vmexit handler vmx_vmexit_handler(). ...

You advice was most helpful once again.  However, I'm now even more
confused than I was before.  I downloaded the OpenSuse source RPM for
xen (xen-4.0.0_21091_06-0.1.1.src.rpm) and added printk debugging
statements as suggested.  The following are the outputs I eventually
found most useful.  All expressions denote existing source code

(XEN) sh_page_fault va=303b90, regs->error_code=3
(XEN) x86_emulate: b=dd, modrm=31, modrm_reg=6
(XEN) sh_page_fault called x86_emulate va=303b90,result=1
(XEN) vmx_vmexit_handler reason=0
(XEN) vmx_vmexit_handler intr_info=80000b0e, vector=e

The key line is:
(XEN) x86_emulate: b=dd, modrm=31, modrm_reg=6

The instruction I'm executing is:

c0817476: dd 31 fnsave (%ecx)

Opcode 0xDD and the modrm_reg (0x6) matches.  The source for
x86_emulate() opcode 0xdd has no case for modrm_reg=0x6, so
x86_emulate() returns X86EMUL_UNHANDLEABLE (i.e., 1).

What I don't understand is why fnsave works before I turn on paging
and doesn't afterwords.

Am I just looking at an unimplemented feature, or is there something
more nefarious going on?

I haven't looked at why load task register (ltr) and 
accesses to the APIC behave similarly.  Does Xen assume
fnsave, ltr, etc. happen with paging turned off?

This message is intended only for the use of the individual or entity to which 
it is addressed. If the reader of this message is not the intended recipient, 
or the employee or agent responsible for delivering the message to the intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of this message is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the sender 
of this E-Mail by return E-Mail or by telephone. 

Xen-devel mailing list