On 16/07/2019 17:40, Jan Beulich wrote: > 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 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.
Looking again, and at v2, I think this is a consequence of our insane !x2apic interrupt set up, where we wrap an already-established system with interrupt remapping. Longer term, when we undo that, we should have far more clear code structure. Therefore, I think it is fine for now. Acked-by: Andrew Cooper <andrew.coop...@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
