On Thu, 24 Sep 2015, Qais Yousef wrote: > The CPUs we want to send the IPI to are not Linux CPUs only. My use case is > about sending IPI to audio coprocessor. > So "dest" doesn't have to be part of Linux online CPUs, hence we need to > specify it so that the underlying controller will know how to map to that CPU. > I should have put more info in the cover letter, not just the link to the > discussion, apologies for that. > > I'm not sure about cpu hotplug. We could call irq_destroy_ipi() when a cpu is > hot unplugged, but the current behaviour is to statically reserve the IPI and > keep them reserved. I think it makes sense to keep it this way for SMP IPIs or > things will get complicated. Right. For general IPIs which are destined to all Linux CPUs we keep them reserved unless the facility which needs them is shut down. CPU hotplug is just disabling the IPI reception on the particular core, but does not change the reservation for e.g. the resched IPI. > For a coprocessor, if we the 'module is unloaded', I'd expect the > irq_destroy_ipi() to be called returning the reserved IPI to the pool. For any case which shuts down a IPI based facility (coprocessor or general) we want to return the IPI. Otherwise we leak the IPI on module removal and allocate a new one on reload. Thanks, tglx
