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: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Su, Disheng" <disheng.su@xxxxxxxxx>, "Tim Deegan" <Tim.Deegan@xxxxxxxxxx>
Subject: RE: [Xen-devel] write page table in user mode
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Sat, 2 Feb 2008 23:29:13 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 02 Feb 2008 07:30:44 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C3CA39AE.13328%Keir.Fraser@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: <D470B4E54465E3469E2ABBC5AFAC390F024D8F32@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C3CA39AE.13328%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchlAD52qky2ju36Tga/OqdSA6cQoQAhnMnzAAblEqAAAw9UHQAACYxg
Thread-topic: [Xen-devel] write page table in user mode
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
>Sent: 2008年2月2日 23:16
>On 2/2/08 14:08, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>> Maybe we can disable such heuristics only when observing guest
>> clear CR0.wp actively? Or later out-of-sync can also help here.
>> BTW, it's worthy of adding a seperate perfc counter for user-level
>> access caused unshadow. :-)
>Yes, and if we can do better at working out when pages should 
>be unshadowed,
>we can then perhaps get rid of the unshadow-on-user-access heuristic.
>Presumably things still work though? The page will simply get 
>re-shadowed on
>next use. I suppose the guest will crash if the shadow code is 
>unable to
>unshadow the page though (e.g., because it is current base 
>page directory).
>Perhaps we should emulate the access anyway if the page cannot be

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?

As long as the right write doesn't affect instruction itself, forward progress
can be anyway assured though performance is bad at thrash between
unshadow and reshadow...


Xen-devel mailing list