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] shadow OOS and fast path are incompatible

To: Gianluca Guida <gianluca.guida@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] shadow OOS and fast path are incompatible
From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Date: Fri, 3 Jul 2009 09:50:17 +0100
Cc: Frank van der Linden <Frank.Vanderlinden@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 03 Jul 2009 01:51:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <f8877f640907021442u3ad44b64o3396fadca3d71fa8@xxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4A4D18DE.6070306@xxxxxxx> <f8877f640907021442u3ad44b64o3396fadca3d71fa8@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.17 (2007-11-01)

At 22:42 +0100 on 02 Jul (1246574577), Gianluca Guida wrote:
> CPU0 doesn't resync a whole L1 page because it's accessing it. There
> are other reasons for a resync here (especially if the guest is 64
> bit), but most probably the resync happen because CPU0 is unsyncing
> another page. Anyway yes, it's highly unlikely but this race can
> definitely happen. I think I never saw it.

Yes.  The fast-not-present path is safe without OOS because the changing
L1 would have to be as a result of the guest writing it, which is a race
on real hardware.   The fast-MMIO path is OK even with OOS because it
only caches present entries, but for proper safety we might want to
avoid using fast-path MMIO if the guest maps MMIO space read-only (does
anyone actually do that?)

> > I haven't checked the fast emulation path, but similar problems might be
> > lurking there in combination with OOS.
> I think that it should be safe enough, but yes another look at it
> should be worth it.

I think you might as well kill the fast emulation path too, while you're
in there. :)  The OOS optimization makes it mostly redundant, and it
just adds complexity now.



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

Xen-devel mailing list