linux-kernel - Re: Xen and incorporating event channels in to nr

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 16 Feb 2011 16:56:51 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Ian Campbell <Ian.Campbell@...rix.com>
cc:	xen-devel <xen-devel@...ts.xensource.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: Xen and incorporating event channels in to nr_irqs

Ian,

On Wed, 16 Feb 2011, Ian Campbell wrote:
> I'd very much like to remove this workaround (better described as a hack
> I think) but in order to do so I need to make sure there are plenty of
> IRQs between nr_irqs_gsi and nr_irqs. Effectively what we would like to
> do is:
> 	nr_irqs += NR_EVENT_CHANNELS;
> somewhere, except obviously we don't want to just drop that into generic
> code!
> 
> Do you have any hints as to an appropriate existing interface which
> could Xen use here?
> 
> If not any suggestions for what sort of interface might be acceptable to
> add?
> 
> For example I was wondering about adding x86_info.irqs.probe_nr_irqs,
> which returns a platform specific additional number of IRQs, and having
> arch_probe_nr_irqs += that value into its calculations.

I'm about to remove the nr_irqs NR_IRQS limitation. It's silly when we
deal with sparse irqs. So the idea is to have the initial nr_irqs set
in early boot to have a sensible size for allocating stuff. Later on
we can expand nr_irqs when the need arises.

It's not only Xen which wants to eliminate the limitation. Think about
irq expanders which are detected late in the boot. We have no sensible
way to reserve enough numbers for them at early boot as we dont know
whether that hardware is there or not.

So my plan for .39 is to ignore the NR_IRQS limitation in the sparse
case and make nr_irqs expandable of course with a sensible upper limit
in the core code itself. It's basically the allocation bitmap which
limits it, but I doubt we'll hit 1 Million irq numbers in the
forseeable future.

Thanks,

	tglx
--
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/