On Wed, Aug 26, 2020 at 01:17:14PM +0200, Thomas Gleixner wrote: > + * ims_queue_info - Information to create an IMS queue domain > + * @queue_lock: Callback which informs the device driver that > + * an interrupt management operation starts. > + * @queue_sync_unlock: Callback which informs the device driver that an > + * interrupt management operation ends. > + > + * @queue_get_shadow: Callback to retrieve te shadow storage for a MSI > + * entry associated to a queue. The queue is > + * identified by the device struct which is used for > + * allocating interrupts and the msi entry index. > + * > + * @queue_lock() and @queue_sync_unlock() are only called for management > + * operations on a particular interrupt: request, free, enable, disable, > + * affinity setting. These functions are never called from atomic context, > + * like low level interrupt handling code. The purpose of these functions > + * is to signal the device driver the start and end of an operation which > + * affects the IMS queue shadow state. @queue_lock() allows the driver to > + * do preperatory work, e.g. locking. Note, that @queue_lock() has to > + * preserve the sleepable state on return. That means the driver cannot > + * disable preemption and (soft)interrupts in @queue_lock and then undo > + * that operation in @queue_sync_unlock() which restricts the lock types > + * for eventual serialization of these operations to sleepable locks. Of > + * course the driver can disable preemption and (soft)interrupts > + * temporarily for internal work. > + * > + * On @queue_sync_unlock() the driver has to check whether the shadow state > + * changed and issue a command to update the hardware state and wait for > + * the command to complete. If the command fails or times out then the > + * driver has to take care of the resulting mess as this is called from > + * functions which have no return value and none of the callers can deal > + * with the failure. The lock which is used by the driver to protect a > + * operation sequence must obviously not be released before the command > + * completes or fails. Otherwise new operations on the same interrupt line > + * could take place and change the shadow state before the driver was able > + * to compose the command.
I haven't looked through everything in detail, but this does look like it is good for the mlx5 devices. Looked like it was only one small update to the set_affinity, so not very disruptive? Thanks, Jason _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu