On 27/06/2019 16:23, Jan Beulich wrote: > While for 32-bit IRTEs I think we can safely continue to assume that the > writes will translate to a single MOV, the use of CMPXCHG16B is more
The CMPXCHG16B here is stale. > heavy handed than necessary for the 128-bit form, and the flushing > didn't get done along the lines of what the specification says. Mark > entries to be updated as not remapped (which will result in interrupt > requests to get target aborted, but the interrupts should be masked > anyway at that point in time), issue the flush, and only then write the > new entry. In the 128-bit IRTE case set RemapEn separately last, to that > the ordering of the writes of the two 64-bit halves won't matter. > > In update_intremap_entry_from_msi_msg() also fold the duplicate initial > lock determination and acquire into just a single instance. > > Signed-off-by: Jan Beulich <jbeul...@suse.com> > --- > RFC: Putting the flush invocations in loops isn't overly nice, but I > don't think this can really be abused, since callers up the stack > hold further locks. Nevertheless I'd like to ask for better > suggestions. > --- > v2: Parts morphed into earlier patch. > > --- a/xen/drivers/passthrough/amd/iommu_intr.c > +++ b/xen/drivers/passthrough/amd/iommu_intr.c > @@ -238,8 +238,7 @@ static void update_intremap_entry(union > break; > > case irte128: > - ACCESS_ONCE(entry.ptr128->raw[0]) = 0; > - barrier(); > + ASSERT(!entry.ptr128->full.remap_en); > entry.ptr128->raw[1] = > container_of(&full, union irte128, full)->raw[1]; > barrier(); > @@ -308,6 +307,20 @@ static int update_intremap_entry_from_io > } > > entry = get_intremap_entry(iommu->seg, req_id, offset); > + > + /* The RemapEn fields match for all formats. */ > + while ( iommu->enabled && entry.ptr32->basic.remap_en ) Why while? (and by this, what I mean is that this definitely needs a comment, because the code looks like it ought to be an if.) ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
