So I looked into this. It isn't straight forward because you need toInstead of a lockless attribute, how about a ->set_atomic() method. ForYeah, I like this idea. I think we can also get rid of the custom
msi this can be the same as ->set(), for non-msi it can be a function
that schedules the work (which will eventually call ->set()).
The benefit is that we make a decision only once, when preparing the
routing entry, and install that decision in the routing entry instead of
making it again and again later.
workqueue if we do this as well, TBD.
retain some kind of state across the deferment on a per-request basis
(not per-GSI). Today, this state is neatly tracked into the irqfd
object itself (e.g. it knows to toggle the GSI).
So while generalizing this perhaps makes sense at some point, especially
if irqfd-like interfaces get added, it probably doesn't make a ton of
sense to expend energy on it ATM. It is basically a generalization of
the irqfd deferrment code. Lets just wait until we have a user beyond
irqfd for now. Sound acceptable?
In the meantime, I found a bug in the irq_routing code, so I will submit
a v3 with this fix, as well as a few other things I improved in the v2
series.