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


[Xen-devel] Re: [RFC]vmx: Enable direct hardware n/p fault injection

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: [Xen-devel] Re: [RFC]vmx: Enable direct hardware n/p fault injection
From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Date: Tue, 12 Feb 2008 08:30:15 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 12 Feb 2008 00:31:31 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F024D8F4B@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>
References: <D470B4E54465E3469E2ABBC5AFAC390F024D8F4B@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-08-11)

At 15:24 +0800 on 04 Feb (1202138657), Tian, Kevin wrote:
> VT-x supports direct reflect for some type of page faults,
> without triggering VM-exit. At least we can utilize this
> feature to accelerate guest n/p fault. The key thing is
> to only clear shadow present bit if guest entry really does.
> All other cases are considered out-of-sync (oos) with guest
> which thus are all set with a special magic with reserved
> bit set.
> Effectively this just replaces fast n/p injection at same
> places, and is also controlled by SHOPT_FAST_FAULT_PATH.
> Thus the gain of this change is straightforward to release
> vmexit/vmentry overhead for existing fast n/p path, though
> it's already 'fast', with negligible overhead on other
> paths when checking shadow flags.
> Our test shows no obvious increase for some benchmark
> scores, then with 0.9% improvement for PAE KB, and 0.7%
> for PAE windows sysbench. It depends on frequency of
> guest n/p fault.

It's a clever idea, though it does add yet one more level of
brain-twisting to the shadow code. :)  I'm hoping to measure what this
looks like on AMD machines this week; the extra code on hot paths will
potentially make a measurable slowdown there.


Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

Xen-devel mailing list

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