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

[Xen-devel] unable to capture an expected page fault


I was trying to modify part of Xen and faced a page fault missing issue. 

I am testing a PV Linux 64-bit guest (kernel 3.1.1, as dom0, the only domain in my setting) atop Xen 4.1.2. In an unmodified Xen, the Linux kernel's "native_set_pte" in "arch/x86/include/asm/pgtable_64.h" traps into Xen due to Xen's write-protection of the pagetable page. But in our modified version, this expected page fault seems missing. 

I tried to debug and had the following observations.

(1) I have verified that the (L1) pte pointing to the page containing the faulting vaddr has its R/W=0 so it is indeed write-protected. 

(2) In Xen, I have verified that the page_fault interrupt is trapped (the "set_intr_gate" logic for page fault in xen/arch/x86/traps.c remains unchanged compared with original Xen). 

(3) And I called printk directly from within "ENTRY(page_fault)" (xen/arch/x86/x86_64/entry.S) in the hope that if the expected faulting vaddr is detected (my understanding is that ENTRY(page_fault) is the first code that gets executed in Xen when there is a page fault interrupt, am I right?), then the printk message will immediately appear. I can see this debug message if I insert the printk to unmodified Xen's entry.S, but it does not generate any output in the modified project. 

(4) I also checked the value of CR0 just in case the WP bit is mistakenly cleared. And I found that it was correctly set. (is this really related? I assume PV is running with CPL==1 so I would like to check this. )

So I was baffled with the situation that modifying a write-protected page does not generate a page fault that can be intercepted by (modified) Xen. 

Could someone suggest some thoughts on my above debugging procedure? 


Xen-devel mailing list



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