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]

Date:	Thu, 20 Nov 2008 12:22:33 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jeremy Fitzhardinge <jeremy@...p.org>
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

Jeremy Fitzhardinge <jeremy@...p.org> writes:

> Ingo Molnar wrote:
>> * Jeremy Fitzhardinge <jeremy@...p.org> wrote:
>>
>>
>>> Writes to the IO APIC are paravirtualized via hypercalls, so implement
>>> the appropriate operations.
>>>
>>> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
>>> ---
>>>  arch/x86/xen/Makefile    |    3 +-
>>> arch/x86/xen/apic.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++
>>>  arch/x86/xen/enlighten.c |    2 +
>>>  arch/x86/xen/xen-ops.h   |    2 +
>>>  4 files changed, 72 insertions(+), 1 deletion(-)
>>>
>>
>> hm, why is the ioapic used as the API here, and not an irqchip?
>>
>
> In essence, the purpose of the series is to break the 1:1 relationship between
> Linux irqs and hardware GSIs.

Bad idea (I think).  We have a 1:1 relationship between the linux irq number and
the GSI because it makes the code dramatically simpler, and it took significant
work to get there.  The concept of an intermediate mapping layer sounds nasty.
But I haven't yet read the patch.

> If the x86 interrupt layer in general decouples irqs from GSIs, then I can
> probably make use of that to clean things up.  A general irq allocator along
> with some way of attaching interrupt-source-specific information to each irq
> would get me a long way, I think.  I'd still need hooks to paravirtualize the
> actual ioapic writes, but at least I wouldn't need to have quite so much
> delicate hooking.

I know that is where I thought the sparse irq code was going.

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/