x86/sfi: fix ioapic gsi range
in [Kernel]
|
Prev: Fwd: EXT3 File System Corruption 2.6.34
Next: 2.6.35-rc2-git1 - include/linux/cgroup.h:534 invoked rcu_dereference_check() without protection!
From: Eric W. Biederman on 8 Jun 2010 17:30 jacob pan <jacob.jun.pan(a)linux.intel.com> writes: > On Tue, 08 Jun 2010 12:41:45 -0700 > ebiederm(a)xmission.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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 8 Jun 2010 18:00 "H. Peter Anvin" <hpa(a)zytor.com> writes: > On 06/08/2010 01:59 PM, Eric W. Biederman wrote: >> >> No. There is no reason to loose 16 IDT entries indefinitely. We may >> need a boot time allocation when we see we have isa irqs, to replace >> the static allocation that we have. But for the most part we dynamically >> idt entries aka vector numbers today, and there is no reason we can't >> generalize that in the future. >> > > Well, that boot time allocation is one of the things > legacy_pic->nr_legacy_irq is used for, and it really makes sense, I > think. I would really like to move away from a compile-time allocation, > and I still find it hard to believe it has a reason to exist. Interesting. Using legacy_pic->nr_legacy_irqs certainly isn't the right way to handle that. We should just have an init method for the legacy_pic that just allocates what it needs when it is initialized. I think we can now run in either just pic mode or just apic mode and so can kill any code for switching from one mode to another. That led to all kinds of complexity. As time and priorities permit I will send/review patches cleaning up the linux irq code. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: jacob pan on 8 Jun 2010 18:20 On Tue, 08 Jun 2010 14:22:18 -0700 ebiederm(a)xmission.com (Eric W. Biederman) wrote: > jacob pan <jacob.jun.pan(a)linux.intel.com> writes: > > > On Tue, 08 Jun 2010 12:41:45 -0700 > > ebiederm(a)xmission.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? > yes, merged. > 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 > [jacob pan] In arch/x86/kernel/mrst.c we parse SFI MTMR table then add timer irqs to mp_irqs. what is broken by this patch is pin_2_irq() lookup for the legacy irq range since we want NR_IRQS_LEGACY to be 0 on Moorestown. We do have the assumption that mp_irqs from SFI is 1:1 mapped to IRQs. Doing this can fix the problem, but you mentioned you have to use NR_IRQS_LEGACY, which i still don't understand. --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -1032,7 +1032,7 @@ static int pin_2_irq(int idx, int apic, int pin) } else { u32 gsi = mp_gsi_routing[apic].gsi_base + pin; - if (gsi >= NR_IRQS_LEGACY) + if (gsi >= legacy_pic->nr_legacy_irqs) irq = gsi; The second problem is nr_irqs_gsi gets an extra 16 for Moorestown. Similarly, we need this in probe_nr_irqs_gsi: - nr = gsi_top + NR_IRQS_LEGACY; + nr = gsi_top + legacy_pic->nr_legacy_irqs; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 8 Jun 2010 18:20 Yuhong Bao <yuhongbao_386(a)hotmail.com> writes: >> IRQ 14/15 is wrong for ATA today as its AHCI based on modern boxes > Not to mention even before that there was native mode IDE!In fact, XP SP1 and later support switching to native mode IDE on BIOSes supporting it as described in this document:http://www.microsoft.com/whdc/device/storage/Native-modeATA.mspx One of these days we may even get a system where the designers really care for being simple and easy to use by software. Where all devices will be discoverable pci devices, and all irqs will be msi or msi-x. No ioapics, no irq routing tables, just nice simple standards conformant hardware that we already support. Until then I guess we get things like Moorestown which are effectively a reinvention of ISA based systems, with different firmware, and different non-standard ISA devices. It isn't particularly fun to smash yet another incompatible idea into the existing infrastructure. The cleanups that introduce modularity, flexibility, and maintainability for irq handling are barely keeping ahead of new poorly integrated features that make the code brittle again. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 8 Jun 2010 18:30
> Until then I guess we get things like Moorestown which are effectively > a reinvention of ISA based systems, with different firmware, and I'm not quite sure where you get that idea from ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |