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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.LFD.2.00.1102161722290.2701@localhost6.localdomain6>
Date:	Wed, 16 Feb 2011 17:25:48 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Ian Campbell <Ian.Campbell@...citrix.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

On Wed, 16 Feb 2011, Ian Campbell wrote:

> On Wed, 2011-02-16 at 15:56 +0000, Thomas Gleixner wrote:
> > 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.
> 
> That sounds ideal, thanks! 
> 
> I was hoping to get rid of the workaround in Xen events.c in the 2.6.39
> timeframe too.
> 
> If you let me know when you have something I can test I'll combine with
> the Xen side and give it a spin.
> 
> On a vaguely related note, what is the future of non-sparse IRQs (on x86
> and/or generally)?

In general I want to switch everything over to SPARSE_IRQ. When the
open coded access to irq_desc[] is gone, which should be mostly the
case in .39 then switching everything over should be a smooth
thing. For those archs which do not want to adjust the numbers
dynamically we simple allocate NR_IRQS in early_irq_init(). So they
wont even notice.

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/