On 13/06/2019 14:28, 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 > 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>
Looking at this patch, I think quite a bit of it should be folded into patch 4. However, my review suggestions on that patch take precedent over the net result here. > --- > 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. Lets focus on getting it functioning first, and fast second. However, I think we can do better than the loop. Let me dig some notes out. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
