From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [v4 11/17] vt-d: Add API to update IRTE when VT-d
	PI is used
Date: Thu, 23 Jul 2015 16:55:00 +0100
Message-ID: <55B10E54.8050407@citrix.com>
References: <1437651353-5275-1-git-send-email-feng.wu@intel.com>
	<1437651353-5275-12-git-send-email-feng.wu@intel.com>
	<55B0F17D.1060702@citrix.com>
	<55B129C90200007800094C1D@prv-mh.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <55B129C90200007800094C1D@prv-mh.provo.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>, Feng Wu <feng.wu@intel.com>, xen-devel@lists.xen.org
Cc: Yang Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>, Keir Fraser <keir@xen.org>
List-Id: xen-devel@lists.xenproject.org

On 23/07/15 16:52, Jan Beulich wrote:
>>>> On 23.07.15 at 15:51, <andrew.cooper3@citrix.com> wrote:
>> On 23/07/15 12:35, Feng Wu wrote:
>>> +    GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, remap_index, iremap_entries, p);
>>> +
>>> +    old_ire = new_ire = *p;
>>> +
>>> +    /* Setup/Update interrupt remapping table entry. */
>>> +    setup_posted_irte(&new_ire, pi_desc, gvec);
>>> +    ret = cmpxchg16b(p, &old_ire, &new_ire);
>>> +
>>> +    ASSERT(ret == *(__uint128_t *)&old_ire);
>> This cannot be correct.  Either the cmpxchg() is required and you must
>> cope with it failing, or the cmpxchg() is not required and this should
>> be a plain write.
> Not exactly: The cmpxchg() is required for this to be an atomic
> 128-bit write. And hence I would view the ASSERT() as
> appropriate - it validates that the entry didn't change behind our
> back.

But p is an active descriptor, which means hardware is liable to change
it behind our back.

~Andrew