| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] x86-64 problem with invalid page fault inlinux 2.6.16-rc
>>> "Nakajima, Jun" <jun.nakajima@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home