linux-kernel - Re: [PATCH] x86/sfi: fix ioapic gsi range

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: <m1sk4x9q45.fsf@fess.ebiederm.org>
Date:	Tue, 08 Jun 2010 14:22:18 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	jacob pan <jacob.jun.pan@...ux.intel.com>
Cc:	Alan Cox <alan@...ux.intel.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	Feng Tang <feng.tang@...el.com>,
	Len Brown <len.brown@...el.com>
Subject: Re: [PATCH] x86/sfi: fix ioapic gsi range

jacob pan <jacob.jun.pan@...ux.intel.com> writes:

> On Tue, 08 Jun 2010 12:41:45 -0700
> ebiederm@...ssion.com (Eric W. Biederman) wrote:
>
>
>> Even if sfi is never implemented on a platform where that kind of
>> hardware exists, the current sfi code is setup to coexist
>> simultaneously in the kernel with all of the infrastructure of other
>> platforms where those kinds of devices exist.  Which means there can
>> be drivers compiled into your kernel that make assumptions about
>> special properties of the irqs 0-15.
>> 
> SFI code can be compiled in with ACPI at the same time but at runtime
> there is only one used, ACPI take precedence. So there wouldn't be any
> additional conflict caused by SFI added APIC tables.
>
>> As for the question about using legacy_pic to detect the absence of
>> an irq controller that Peter raised.  We can't do that because it
>> should be possible for an acpi system with all of the legacy hardware
>> to exist without needing to implement an i8259, or ever run in the
>> historical interrupt delivery mode of pcs.
> In your case, I don't understand how would it change the calculation of
> irq mapping. Even if you don't use i8259 on a x86 PC platform, you
> still have NR_LEGACY_IRQS=legacy_pic->nr_legacy_irqs.
>
> On the other side, use NR_LEGACY_IRQS breaks the existing code for
> Moorestown in terms of irq-gsi lookup and nr_irqs_gsi.

Is this code merged where I should have fixed it in my patchset?

We went through this with acpi having an identity mapping of irq to
gsi mapping and the result is that we (a) developed  weird platform
specific hooks for things that should have been handled by generic
code, and on other systems we lost access to 16 irqs.

It took probably 10 years to sort the acpi irq handling out.  What
I have learned along the way is:
- Sharing irq in software is madness, so a one to one mapping with
  hardware irq is required.
- An identity mapping with gsis is nice but we can't count on the hardware
  designers or the spec designers always doing sane and reasonable things
  so not guaranteeing a particular mapping is important.

If I have actually broken any sfi drivers because you assumed a
particular we are back where we were with ISA, and still haven't
completely escaped.  The abstraction layer should provide all of
the mapping so drivers only see linux irq numbers.

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/