Re: Question about interrupt routing and irq allocation

[Eric W. Biederman]

Jeremy Fitzhardinge <jeremy@xxxxxxxx> writes:

> Ingo Molnar wrote:
>>> I'm initially targeting 32-bit, though obviously I'd like something that
>>> works for both 32 and 64 bit.  irq_cfg[] is missing in io_apic_32.c; would I
>>> achieve the same effect by setting irq_vector[irq] = 0xff or something?
>>>
>>
>> ok, here comes the next phase of a rather cunning plan: please unify these
>> vector allocators first! ;-)
>>
>
> Somehow I knew you were going to say that...
>
>> it's nontrivial but would result in rather nice code. I dont know whether we
>> want to extend per-CPU vectors to 32-bit as well ... but might be worth an
>> attempt and we could give any exploratory patches a try in -tip. Eric, what do
>> you think about the general approach?
>>
>> this would also pave the way towards unified APIC code. Hm
>
> All of that sounds very appealing, particularly as the work on xen-dom0
> continues.  But in the meantime I'm just using create_irq(), and I'll wear the
> wasted vector (after all, it will only happen when booting under Xen-hvm).

- I think using create_irq is a good step.
- I think all vectors are wasted in the case of Xen.
- I think we want a individual irq for each xen irq source.
  Sparc already does a demux in similar circumstances with
  a queue of received MSI messages an a single cpu irq
  that these get demuxed from.
  If we don't have individual irqs per drivers it will be hard
  to share a source base with native drivers.
- I think it would be very nice if we could get irqs allocated
  in request_irq instead of create_irq (and equivalents).
  
- I think ultimately it makes sense to port the per vector
  code to 32bit linux.  On single cpu systems the cost should
  be just a hair more code, but no extra data structures.  We
  can easily restrict the irq allocation to allocating the same
  vector on all cpus for any old machines that prove flaky with
  irq migration.

  The code between the two architectures we kept fairly close
  in sync when I worked on it so a merge should not be a big deal.

  Trouble is I'm not finding a lot of time to work on any of this
  stuff lately :(

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/