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: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] shadow OOS and fast path are incompatible
From: Gianluca Guida <gianluca.guida@xxxxxxxxxxxxx>
Date: Fri, 3 Jul 2009 11:11:07 +0200
Cc: Frank van der Linden <Frank.Vanderlinden@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 03 Jul 2009 02:11:35 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=52tVYpWWScxkx/MfAmSNHSJPbfDm5TTEWyIlZlVH4bA=; b=RD+RdhHiKCHIHHgcxO7TrtEt9+0W9MOiRMT3qtEAYgi+DFvwAthIhfh1l+XGVl5nft CYhDG3+Ir8yyVMGXAwlvT6ScnWMCDb0FHl0kCcRxB4ucTO4ENd5dm602F59GqZFXXqOx z7SfFBYYyeAjp0btClEENwz9116UG/XLwIr7w=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UzZ9LqJXdzaQE/98Ez0P+Pvr9kac0vAswz7GHfpLb+z08YOPdPnNpey0vQPbT08gEU tbjYQwZ0+cM8ivlywxUmX7R4lBWip62/34xDnx/CH6Rbi2lyKYqjAYPTofXt11Ns6ZDV YUai8vZ5Rg3CcRtvZtYbmfbtmENyi2JxdmrHs=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090703085017.GU16056@xxxxxxxxxxxxxxxxxxxxx>
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> <20090703085017.GU16056@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On Fri, Jul 3, 2009 at 10:50 AM, Tim Deegan<Tim.Deegan@xxxxxxxxxx> wrote:
> 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?)

Yes, the subject of this thread is incorrect, OOS is incompatible only
with *current* fast gnp code. This bug is easily fixable by checking
if the page is out of sync (and go to the fast path) *before* checking
for the l1 being a special entry. This will remove the race and make
the fast gnp correct again with OOS -- I guess, but I perhaps
shouldn't write about shadow SMP races before breakfast.

But, as I said, there's really no point in keeping the fast gnp path
there already, so I'd be for removing.

>> > 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.

Yes, that was on the list as well. Yet, on a correctness point of
view, I think it's safe -- again, no-caffeine warning. The fast
emulation is very simple, and activate in a very particular case: two
emulation in a row, without any other pagefault in between.


It was a type of people I did not know, I found them very strange and
they did not inspire confidence at all. Later I learned that I had been
introduced to electronic engineers.
                                                  E. W. Dijkstra

Xen-devel mailing list