On 23/07/15 16:52, Jan Beulich wrote: >>>> On 23.07.15 at 15:51, <andrew.coop...@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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
