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] [day] [month] [year] [list]

Date:	Thu, 10 Jun 2010 07:39:50 -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:

> Eric W. Biederman Wed, 09 Jun 2010 16:44:11 -0700
>>jacob pan <jacob.jun.pan@...ux.intel.com> writes:
>>
>>> [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.
>>
>>NR_IRQS_LEGACY is a constant of 16.
> i know, what i meant is we want this to be a variable.

No.  Not on that code path.  As that code path has nothing
to do what what hardware is present.

There are a bunch of other very awkward usages of
legacy_pic->nr_legacy_irqs that should be removed with cleanups.

Things like EISA_ELCR are very wrong to have a variable in there.
We already have a probe for ISA being present so we don't need an
extra one.

>>> Doing this can fix the problem, but you mentioned you have to use
>>> NR_IRQS_LEGACY, which i still don't understand.
>>
>>Looking at the code in io_apic.c there is a relatively clean way to
>>handle this.  The actual concept in io_apic.c today is mp_bus_not_pci.
>>
>>So you just need to do:
>>
>>diff --git a/arch/x86/kernel/mrst.c b/arch/x86/kernel/mrst.c
>>index e796448..9377fda 100644
>>--- a/arch/x86/kernel/mrst.c
>>+++ b/arch/x86/kernel/mrst.c
>>@@ -242,4 +242,5 @@ void __init x86_mrst_early_setup(void)
>> 	x86_init.mpparse.find_smp_config = x86_init_noop;
>> 	x86_init.mpparse.get_smp_config = x86_init_uint_noop;
>> 
>>+	set_bit(0, mp_bus_not_pci);
>> }
>>
>>
>>Then you get treated as ISA for purposes of pin_2_irq, and everything
>>is a pass through.  Since that seems to be what you want anyway I don't
>>see a problem with that for now.
>>
> I think this may work better. Since we already assign srcbus = MP_ISA_BUS to 
> use the mp_irqs, this may be more inline with the current code.
> Thanks for the pointer.
>
> But the nr_irqs_gsi would still be wrong for Moorestown if don't use legacy_pic
> or some sort of runtime detection.

nr_irqs_gsi has a possibly confusing name.

nr_irqs_gsi is the number of linux irqs that we reserve for handling
the gsis.  All of the rest of the irqs are allowed to be dynamically
allocated for MSIs and the like.  As long as the number is >= the number
of gsis you are fine. 

Unless you have patches that do strange and use nr_irqs_gsi for something
else I don't see why you would have a problem with nr_irqs_gsi.

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/