Re: [Xen-devel] Every page fault caused pagetable walk when using xenoprofile

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

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@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

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