Re: [PATCH] x86_64: Dynamically allocate arch specific system vectors

[ebiederm@xmission.com (Eric W. Biederman)]

Cliff Wickman <cpw@sgi.com> writes:
>
> I assume you mean create_irq() and destroy_irq().
> They are close to what we need.

Actually that isn't quite what I was thinking.

> However for any given system use:
> - we need to request a high priority vector for some irq's, rather than
>   one randomly allocated as per __assign_irq_vector().

Well I was actually thinking mostly about reusing assign_irq_vector.

The high priority vector seems to be the place where we would need
to reexamine the vector allocator.

> - we want the irq/vector to be targeted to all cpu's (as specified in a
>   mask,
>   and can include currently offline cpu's) rather than a single cpu. 

__assign_irq_vector should be able to handle that case.

> I suppose those abilities could be added to create_irq(), but we didn't
> want to intrude into that interface.

Right.  That part gets custom and there is no intersection.

> A smaller consideration is simplicity of use.  We want any such user to
> use
> the generic do_IRQ() flow (not alloc_intr_gate()).

My primary concern is that you are generalizing an interface that is
designed for alloc_intr_gate consumers.  In particular for people
who wish to allocate vectors that can be triggered by software to
do this.

If this is normal irq handling I would really prefer to use the
normal data structures that we use for allocating vectors to irqs,
because that is what you are doing.

> But make it easy to set
> up the irq/vector, irq_chip and irq_desc without getting intimate with
> the details.
> I suppose some other wrapper for an enhanced create_irq() could be done.
>
> We are going to need such irq/vector pairs for a couple of UV drivers
> (drivers/misc/sgi-gru/ and sgi-xp/).  And would prefer it for the UV TLB
> shootdown (x86/kernel/tlb.uv.c) rather than using alloc_intr_gate().

I also want to ask why do you need an irq that fires on every cpu?

That concept seems to be responsible for one of the nastiest data
structures in the kernel.  Where we track how many times any irq has
occurred on any cpu.  Look at the percpu variable kernel_stat.  It
seems to be one of the nastiest variables I know of.  Of size:
NR_CPUS*NR_CPUS*32  Assuming you have a machine with a reasonable
number of irqs per cpu.

Eric