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]

Date:	Wed, 09 Jun 2010 16:44:11 -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:

> [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.

> 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.

Using legacy pic to even talk about this behavior is wrong as that is
hardware abstraction and the presence or absence of an i8259 has
nothing to do with the presence of ISA irqs and their descendants.

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/