WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] x86-64 problem with invalid page fault in linux 2.6.16-r

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] x86-64 problem with invalid page fault in linux 2.6.16-rc1
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 20 Jan 2006 18:06:21 +0100
Cc: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Fri, 20 Jan 2006 17:14:08 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <6a876bf531b4531eb8889e96a14116c8@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <43D114D3.76F0.0078.0@xxxxxxxxxx> <6a876bf531b4531eb8889e96a14116c8@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>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?

>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

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

<Prev in Thread] Current Thread [Next in Thread>