ZelluX
2009-Jul-17 07:15 UTC
[Xen-devel] 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
Tim Deegan
2009-Jul-17 09:20 UTC
Re: [Xen-devel] Every page fault caused pagetable walk when using xenoprofile
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 ffffffffffffffffThat''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