Hi Thomas,
On 11/16/2015 05:17 PM, Thomas Gleixner wrote:
1) IPI as per_cpu interrupts
Single hwirq represented by a single irq descriptor
2) IPI with consecutive mapping space
No extra mapping from virq base to target cpu required as its just
linear. Everything can be handled via the base virq.
I think I am seeing a major issue with this approach.
Take the case where we reserve an IPI with ipi_mask that has cpu 5 and 6
set only. When allocating a per_cpu or consectuve mapping, we will
require 2 consecutive virqs and hwirqs. But since the cpu location is
not starting from 0, we can't use the cpu as an offset anymore.
So when a user wants to send an IPI to cpu 6 only, the code can't easily
tell what's the correct offset from base virq or hwirq to use.
Same applies when doing the reverse mapping.
In other words, the ipi_mask won't always necessarily be linear to
facilitate the 1:1 mapping that this approach assumes.
It is a solvable problem, but I think we're losing the elegance that
promoted going into this direction and I think sticking to using struct
ipi_mapping (with some enhancements to how it's exposed an integrated
by/into generic code) is a better approach.
Thoughts?
I still don't have a working implementation otherwise I would have sent
my patches, but I thought I'd raise this up before I spend more time on
it unnecessarily.
Thanks,
Qais
