Re: [PATCH 0/6] Implement generic IPI support mechanism

From: Qais Yousef
Date: Wed Sep 30 2015 - 09:34:54 EST

On 09/29/2015 09:48 PM, Thomas Gleixner wrote:

Now how these hwirqs are allocated is a domain/architecture
specific issue.

x86 will just find a vector which is available on all target
cpus and mark it as used. That's a single hw irq number.

mips and others, which implement IPIs as regular hw interrupt
numbers, will allocate a these (consecutive) hw interrupt
numbers either from a reserved region or just from the
regular space. That's a bunch of hw irq numbers and we need
to come up with a proper storage format in the irqdata for
that. That might be

struct ipi_mapping {
unsigned int nr_hwirqs;
unsigned int cpumap[NR_CPUS];

Can we use NR_CPUS here? If we run in UP configuration for instance, this will be one. The coprocessor could be outside the NR_CPUS range in general, no?

How about

struct ipi_mapping {
unsigned int nr_hwirqs;
unsigned int nr_cpus;
unsigned int *cpumap;

where cpumap is dynamically allocated by the controller which has better knowledge about the supported cpu range it can talk to?

This made me realise another problem. struct cpumask is dependent on NR_CPUS. I can use the generic BITMAP I suppose?

or some other appropriate storage format like:

struct ipi_mapping {
unsigned int hwirq_base;
unsigned int cpu_offset;
unsigned int nr_hwirqs;

which is less space consuming, but restricted to consecutive
hwirqs which can be mapped to the cpu number linearly:

hwirq = hwirq_base + cpu - cpu_offset;

This could work without worrying about NR_CPUS but it would be nice not to restrict the controller to consecutive hwirqs.

Thanks a lot for the comprehensive pointers!

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at