|
xen-devel
RE: [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
>unshadowed?
>
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...
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home