linux-kernel - Re: [PATCH 30 of 38] xen: implement io_apic

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: <492AFDFC.1020305@goop.org>
Date:	Mon, 24 Nov 2008 11:18:20 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Xen-devel <xen-devel@...ts.xensource.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Ian Campbell <ian.campbell@...rix.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, Yinghai Lu <yinghai@...nel.org>
Subject: Re: [PATCH 30 of 38] xen: implement io_apic_ops

Eric W. Biederman wrote:
> Jeremy Fitzhardinge <jeremy@...p.org> writes:
>
>   
>> Yes, I suppose we can statically partition the irq space.  In fact the original
>> 2.6.18-xen dom0 kernel does precisely that, but runs into limitations because of
>> the compile-time limit on NR_IRQS in that kernel.  If we move to a purely
>> dynamically allocated irq space, then having a sparse allocation if irqs becomes
>> reasonable again, for msis and vectorless Xen interrupts.
>>
>>     
>>> The difference is that the xen sources are not delivered using vectors.  The cpu
>>> vector numbers we do hide and treat as an implementation detail.  And I am totally
>>> happy not going through the vector allocation path.
>>>
>>>       
>> Right.  And in the physical irq event channel case, the vector space is managed
>> by Xen, so we need to use Xen to allocate the vector, then program that into the
>> appropriate place in the ioapic.
>>     
>
> We should be able to share code with iommu for irqs handling, at first glance you
> are describing a pretty similar problem.  Now I don't know think the interrupt
> remapping code is any kind of beauty but that seems to be roughly what you
> are doing with Xen domU.  I certainly think with some careful factoring
> we can share the ioapic munging code.  And the code to pick how we program
> the ioapics.
>   

Notwithstanding the possibility that there'll be general changes to x86 
interrupt handing in the future, do you have any objection to my patches 
as they stand?  Ingo would like to see your and/or hpa's ack before 
accepting them.

Should I repost them?

Thanks,
    J
--
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/