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/
Home Products Support Community News


Re: [Xen-devel] write page table in user mode

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Su, Disheng" <disheng.su@xxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] write page table in user mode
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sat, 02 Feb 2008 15:58:00 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 02 Feb 2008 07:57:54 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F024D8F35@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchlAD52qky2ju36Tga/OqdSA6cQoQAhnMnzAAblEqAAAw9UHQAACYxgAAFuQz8=
Thread-topic: [Xen-devel] write page table in user mode
User-agent: Microsoft-Entourage/
On 2/2/08 15:29, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> It's said to be a forward progress issue, that instruction page of faulting
> IP falls into mapped virtual range by same L1 as the target frame it tries
> to update. So the implication is that the unshadow unfortunately
> succeeds. Then re-execute faulting IP causes another shadow fault and
> unshadowed L1 is reshadowed again. Finally unshadow and reshadow
> conducts a dead trap. (Disheng is in Chinese New Year vacation now
> and hope I didn't make thing wrong :-)
> For this special case, I guess we may add some postponed track info,
> like if previously unshadowed page triggers a reshadow immediately
> without any other faults in between, we then disable that heuristics on
> this special page. Possibly we can do page-based heuristics, like adding
> one flag with bit set indicating disallowed heuristics?

Ugh, it would be much nicer to remove the unshadow-on-user-access heuristic
entirely. We just need to do enough testing to ensure it doesn't harm
performance in other cases we care about. I really don't know how much we
rely on that heuristic these days. If we can show good performance without
it then I'm happy to remove it (if Tim also agrees).

 -- Keir

Xen-devel mailing list