Xen devel - Jan 2006 - RE: x86-64 problem with invalid page fault inlinux 2.6.16-rc1

Jan Beulich wrote:
>> In SMP systems we need the guest to handle spurious page-not-present
>> faults at any time and at any virtual address. This is a side effect
>> of the writable pagetable implementation.
> 
> So far it was my understanding that writable page tables are not the
> normal way of operating for the guest (I thought this was only
> happening in shadow mode). If that assumption is wrong, why get all
> the page table pages converted to readonly in the kernel? 
Writable page tables are the default operating mode in XenLinux. Xen
write-protects page tables to intercept writes to page tables so that it
can allow the guest to continue on writes while it can check validity of
the modifications when flushing the modifications by making snapshot of
the page table page. Xen also disconnects the such pages by invalidating
the PTE that maps the page.

But if this problem is happening you should see such page faults when
handling page tables.

If you are saying "a subsequent software page table walk shows all
page table entries present", then how about permission? Do they have the
U bit on? 
> 
>> If the vmalloc_fault path no longer covers all of the kernel virtual
>> address space then a spurious-fault detection needs to be added
>> before oops''ing the kernel.
> 
> That would then include the kernel image itself, too. But we never
> see any page faults there. 
> 
> Further, what updating are you talking about - the area for a loaded
> module gets mapped once and then never touched again (and as said in
> the original mail, the faults are occuring long after the affected
> module got loaded)?  
> 
> Jan
> 

Jun
---
Intel Open Source Technology Center

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

>>> "Nakajima, Jun" <jun.nakajima@intel.com> 20.01.06
19:17:31 >>>
>Jan Beulich wrote:
>>> In SMP systems we need the guest to handle spurious
page-not-present
>>> faults at any time and at any virtual address. This is a side
effect
>>> of the writable pagetable implementation.
>> 
>> So far it was my understanding that writable page tables are not the
>> normal way of operating for the guest (I thought this was only
>> happening in shadow mode). If that assumption is wrong, why get all
>> the page table pages converted to readonly in the kernel? 
>
>Writable page tables are the default operating mode in XenLinux. Xen
>write-protects page tables to intercept writes to page tables so that it
>can allow the guest to continue on writes while it can check validity of
>the modifications when flushing the modifications by making snapshot of
>the page table page. Xen also disconnects the such pages by invalidating
>the PTE that maps the page.
set_pte_at(), as I understand it, does a direct write to the page tables (for
kernel space updates, which always are
done on init_mm) only when HYPERVISOR_update_va_mapping() fails. I''ll
yet have to check that this is the case, but I
can''t see why that should fail.

In any case, I think the entire handling should be transparent to the guest
(i.e. no pointless fault should be
forwarded to it). Specifically, if the updating was done asynchronously, and if
you can''t guarantee that this was
finished before the first access, how do you guarantee that this gets finished
by the time the page fault handler of the
guest gets run? And if this in fact is guaranteed by some means, then it should
be simple to use that fact and suppress
propagation of the page fault.
>But if this problem is happening you should see such page faults when
>handling page tables.
Yes, the info Keir gave made likely that the important pattern is the (perhaps
heavy) module loading that happens
during the later boot phase (which implies changes to the page tables); once
boot is done, no (frequent) module loading
normally happens anymore, hence later the fault wasn''t observed
anymore.
>If you are saying "a subsequent software page table walk shows all
>page table entries present", then how about permission? Do they have
the
>U bit on? 
Sure. Error code it zero, so the fault is clearly due to a missing page table
entry at some level.

Jan

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