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: Mon, 15 Nov 2010 16:22:31 -0600
Delivery-date: Mon, 15 Nov 2010 14:24:38 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C903715D.9D64%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
Keir Fraser <keir.xen@xxxxxxxxx> wrote on 11/12/2010 04:34:05 PM:

KF> On 12/11/2010 21:27, "alarson@xxxxxxxx" <alarson@xxxxxxxx> wrote:

AL> (XEN) sh_page_fault va=303b90, regs->error_code=3
AL> (XEN) x86_emulate: b=dd, modrm=31, modrm_reg=6


KF> Since you end up in a loop not progressing past the fnsave
KF> instruction, it seems quite likely that you have a bug and are
KF> writing to a pagetable page.  In fact a pagetable page that maps
KF> something that is needed to execute the fnsave instruction. You
KF> need that page to both be writable (so that fnsave can write its
KF> data) and read-only (because it is a pagetable page that maps
KF> something that is used by the fnsave instruction) and so I'm
KF> guessing you end up in an endless loop with that page flipping
KF> between being read-only and read-write in the shadow page table.

KF> Hope that makes sense. :-)

I understand what you are saying, but I'm confident that's not what's
happening.  Just to be sure, I modified one of our analysis programs
to list all the page tables and the PDT and confirmed that the page at
virtual address 303b90 doesn't map to any of them.  In fact I verified
that none of the present pages maps to any PT or the PDT.

If not, it seems like I need to find out who is calling sh_page_fault,
and that leads me to sh_paging_mode which seems even more of a sticky
tar pit than sh_page_fault.  I think I should be looking at
emulate_gva_to_mfn() and propagate_page_fault(), but I haven't spent
enough time with the code to be sure.  If you have other ideas, I'd
love to hear them.

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