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] Re: changeset 22526:7a5ee3800417

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: changeset 22526:7a5ee3800417
From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Date: Wed, 9 Mar 2011 13:57:28 +0000
Cc: xen devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, ????????? <zpfalpc23@xxxxxxxxx>
Delivery-date: Wed, 09 Mar 2011 05:58:31 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vX65pEy2kWG35gDuSze+4/9DnBZRWmuwFsWexXAX7Oc=; b=Kcx3fMJUOdsmUGwea73YIpkdUfIk0MxIx3DAz6nGWu4Lp84J3hz9fCSr6a6txtnTjq vRfZ2GBYcs4C1M2nX5xSbgFRbI7iFJkiOfa+5sodHBDBTzd7tnS+sF/52diZ5wEhPof4 gJzRrwTqkMBG5JvRSwDE+t519oDnaDsm3/cOI=
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=b2N16xLGfoqYyuvjc7yJECVZ9lnI83dK4tWw8qW+yt4YHSdz1W7GmI3SgQT/+JGeuv WbX3Ze6tnUHGwfxaVXJ01UYtQVe3VBRRuzSxTmgUR1mhJKNslS5Q11gZ1Plb9sc5FLMt ZDFdO2Dh4x8n3q0SsLEYOufhMotdJ9N/28HLo=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110309084448.GF28479@xxxxxxxxxxxxxxxxxxxxxxx>
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: <AANLkTimqNJWRWzSj1BYPP5T7GAhSK_=70T9dq5CW94iB@xxxxxxxxxxxxxx> <1299514840.19262.4698.camel@elijah> <AANLkTimqzZc7B0MG-PoD0ny=mdjrfvbc9ZAWkqQ526VH@xxxxxxxxxxxxxx> <20110307164824.GE28479@xxxxxxxxxxxxxxxxxxxxxxx> <1299517021.19262.4704.camel@elijah> <20110309084448.GF28479@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, Mar 9, 2011 at 8:44 AM, Tim Deegan <Tim.Deegan@xxxxxxxxxx> wrote:
> At 16:57 +0000 on 07 Mar (1299517021), George Dunlap wrote:
>> > Better to use old_entry.mfn, in the spirit of the original cset
>> > ("access-once semantics")?
>> I started to do that, but the one below didn't have an old_entry
>> already.
>> > In fact, I suspect that to be safe, you need
>> > to do an atomic RMW instead of just an atomic set, and then decide
>> > whether the VT-d tables will need to be synced.
>> Are we not holding the p2m lock when writing entries?
> Good point. :)  I would prefer to use old_entry in both places anyway,
> just for consistency with the general approach of reading once.  It
> won't be any slower.

Sure, why not. :-)

> Is this patch intended for 4.1.0?

It looks like by accident, the bug will only cause a performance
degradation -- it will unnecessarily flush the vtd table even if the
mfn for a page isn't changing.  Presumably this will mainly have an
impact on guests which are migrating with PCI pass-through -- is that
even possible?


Xen-devel mailing list