[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: <alarson@xxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxx>
  • Date: Fri, 12 Nov 2010 22:34:05 +0000
  • Cc:
  • Delivery-date: Fri, 12 Nov 2010 14:34:46 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=mhItQW8mgo2nd5Zj87Bk2uIDF/WfArRqPfBzN9NmzHPyVjQ86dbXtjpNkquU4fwRdW TnOHr6cP07gL4YSjkob5JrnZkUklj1KWNckuumKcMDEOFEcKLL1Qr5X+pp5M2wgBJKpr tBG5nPE3hIHfZ1rE6172yhhmRZ8XDl7xqNOAk=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcuCubZYJM5PWPMbJEGM1eamoCS+cg==
  • Thread-topic: [Xen-devel] fxsave, fnsave, ltr hang for guest OS.

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

> 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
> variables:
> 
> (XEN) sh_page_fault va=303b90, regs->error_code=3
> (XEN) x86_emulate: b=dd, modrm=31, modrm_reg=6

So you took a vmexit on a page fault while trying to execute fnsave. The
shadow fault handler then tries to emulate the faulting instruction (fnsave)
presumably because it thinks the instruction is attempting to write to a
page that is read-only in the shadow page tables (generally that would be
because Xen thinks the instruction is trying to write to a page-table page).

> (XEN) sh_page_fault called x86_emulate va=303b90,result=1

Emulation failed, because the emulator does not support fnsave. The shadow
fault handler will take this as a hint that the instrction is not writing to
a page table page, and hence flushes some shadow page table state which is
possibly out of date. This makes the previously read-lonely page writable,
and we expect that on return to guest context the CPU will execute the
previously-faulting instruction without problem.

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

Hope that makes sense. :-)

> 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?

In general those instructions would not even vmexit. The CPU would just
execute them directly. The reason you are having problems when you turn
paging on is probably because of some guest bug where data structures
written yo by FNSAVE, LTR, etc are overlapping with your page tables.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.