Xen devel - Jul 2009 - Every page fault caused pagetable walk when using xenoprofile

Hi, all

I was measuring some performance with help of xenoprofile 0.9.3 on Xen 3.3.0,
and it worked well under direct mode (i.e., no shadow page table enabled)

But when I started Xen with parameter dom0_shadow=1, which enabled shadow page
table, the benchmark performance downgraded greatly when xenoprofile was
started. What's more, after I checked xm dmesg, I found pagetable walks were
triggered several times due to reserved bit in page table:

(XEN) ----[ Xen-3.3.0  x86_64  debug=n  Tainted:    C ]----
(XEN) CPU:    4
(XEN) RIP:    e008:[<ffff828c80152cb6>] __copy_from_user_ll+0x26/0x40
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
==== BLAH BLAH BLAH ===(XEN) Xen call trace:
(XEN)    [<ffff828c80152cb6>] __copy_from_user_ll+0x26/0x40
(XEN)    [<ffff828c801a5cba>] xenoprof_backtrace+0xfa/0x440
(XEN)    [<ffff828c8011c105>] xenoprof_log_event+0xe5/0x1b0
(XEN)    [<ffff828c801a584e>] ppro_check_ctrs+0x9e/0x120
(XEN)    [<ffff828c801a47a9>] nmi_callback+0x29/0x80
(XEN)    [<ffff828c8014e518>] do_nmi+0x38/0x100
(XEN)    [<ffff828c801a6877>] handle_ist_exception+0x52/0x5b
(XEN)
(XEN) d0:v10: reserved bit in page table (ec=0009)
(XEN) Pagetable walk from 0000000000402540:
(XEN)  L4[0x000] = 000000056265c067 5555555555555555
(XEN)  L3[0x000] = 000000056212b067 5555555555555555
(XEN)  L2[0x002] = 000000056215d067 5555555555555555
(XEN)  L1[0x002] = ffffffffffffffff ffffffffffffffff

Has any one been confronted by this problem before?

Many thanks for your replies.

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

At 08:15 +0100 on 17 Jul (1247818543), ZelluX wrote:
> ==== BLAH BLAH BLAH ===
Hey, the registers might have been useful! :)
> (XEN)    [<ffff828c80152cb6>] __copy_from_user_ll+0x26/0x40
> (XEN)    [<ffff828c801a5cba>] xenoprof_backtrace+0xfa/0x440
> (XEN)    [<ffff828c8011c105>] xenoprof_log_event+0xe5/0x1b0
> (XEN)    [<ffff828c801a584e>] ppro_check_ctrs+0x9e/0x120
> (XEN)    [<ffff828c801a47a9>] nmi_callback+0x29/0x80
> (XEN)    [<ffff828c8014e518>] do_nmi+0x38/0x100
> (XEN)    [<ffff828c801a6877>] handle_ist_exception+0x52/0x5b
> (XEN)
> (XEN) d0:v10: reserved bit in page table (ec=0009)
> (XEN) Pagetable walk from 0000000000402540:
> (XEN)  L4[0x000] = 000000056265c067 5555555555555555
> (XEN)  L3[0x000] = 000000056212b067 5555555555555555
> (XEN)  L2[0x002] = 000000056215d067 5555555555555555
> (XEN)  L1[0x002] = ffffffffffffffff ffffffffffffffff
That''s the marker that the shadow pagetables use to register that they
know the equivalent guest L1 entry is not present.  It allows a
lock-free fast path in the shadow pagetable code to be keyed off the
pagefault error code.

In this case, it looks like xen is trying to copy data from a buffer in
dom0 that''s not mapped, which causes a reserved-bit page fault, and
because the fault is taken in Xen context it prints a warning. 

Two things:

 - does xenoprofile normally get a lot of hypercalls returning EFAULT?
   Are you passing buffers to Xen that aren''t mlock()ed?
 
 - does commenting out the call to reserved_bit_page_fault() in
   do_page_fault() make everything Just Work?  I think it should, but
   maybe Keir will disagree.

Cheers

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

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