linux-kernel - Re: Question about interrupt routing and irq allocation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 28 May 2008 02:35:08 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andi Kleen <andi@...stfloor.org>,
	Avi Kivity <avi@...ranet.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Keir Fraser <Keir.Fraser@...citrix.com>
Subject: Re: Question about interrupt routing and irq allocation

Jeremy Fitzhardinge <jeremy@...p.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/