All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] x86: fully honor "nolapic" (take 2)
@ 2009-01-16 11:46 Jan Beulich
  2009-01-16 12:45 ` Ingo Molnar
  0 siblings, 1 reply; 7+ messages in thread
From: Jan Beulich @ 2009-01-16 11:46 UTC (permalink / raw)
  To: mingo, tglx, hpa; +Cc: linux-kernel

"nolapic" should not only suppress SMP and use of the LAPIC, but it
also ought to have the effect of disabling all IO-APIC related activity
as well as PCI MSI and HT-IRQs.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

---
 arch/x86/kernel/apic.c    |    9 ++++++++-
 arch/x86/kernel/io_apic.c |    6 ++++++
 arch/x86/kernel/smpboot.c |    1 +
 3 files changed, 13 insertions(+), 1 deletion(-)

--- linux-2.6.29-rc1/arch/x86/kernel/apic.c	2009-01-14 11:36:05.000000000 +0100
+++ 2.6.29-rc1-x86-no-lapic/arch/x86/kernel/apic.c	2009-01-16 11:57:45.000000000 +0100
@@ -1125,6 +1125,13 @@ void __cpuinit setup_local_APIC(void)
 	unsigned int value;
 	int i, j;
 
+	if (disable_apic) {
+#ifdef CONFIG_X86_IO_APIC
+		disable_ioapic_setup();
+#endif
+		return;
+	}
+
 #ifdef CONFIG_X86_32
 	/* Pound the ESR really hard over the head with a big hammer - mbligh */
 	if (lapic_is_integrated() && esr_disable) {
@@ -1565,11 +1570,11 @@ int apic_version[MAX_APICS];
 
 int __init APIC_init_uniprocessor(void)
 {
-#ifdef CONFIG_X86_64
 	if (disable_apic) {
 		pr_info("Apic disabled\n");
 		return -1;
 	}
+#ifdef CONFIG_X86_64
 	if (!cpu_has_apic) {
 		disable_apic = 1;
 		pr_info("Apic disabled by BIOS\n");
--- linux-2.6.29-rc1/arch/x86/kernel/io_apic.c	2009-01-14 11:36:05.000000000 +0100
+++ 2.6.29-rc1-x86-no-lapic/arch/x86/kernel/io_apic.c	2009-01-13 15:05:37.000000000 +0100
@@ -3258,6 +3258,9 @@ static int msi_compose_msg(struct pci_de
 	int err;
 	unsigned dest;
 
+	if (disable_apic)
+		return -ENXIO;
+
 	cfg = irq_cfg(irq);
 	err = assign_irq_vector(irq, cfg, TARGET_CPUS);
 	if (err)
@@ -3726,6 +3729,9 @@ int arch_setup_ht_irq(unsigned int irq, 
 	struct irq_cfg *cfg;
 	int err;
 
+	if (disable_apic)
+		return -ENXIO;
+
 	cfg = irq_cfg(irq);
 	err = assign_irq_vector(irq, cfg, TARGET_CPUS);
 	if (!err) {
--- linux-2.6.29-rc1/arch/x86/kernel/smpboot.c	2009-01-14 11:36:05.000000000 +0100
+++ 2.6.29-rc1-x86-no-lapic/arch/x86/kernel/smpboot.c	2009-01-14 09:14:16.000000000 +0100
@@ -1125,6 +1125,7 @@ static int __init smp_sanity_check(unsig
 		printk(KERN_ERR "... forcing use of dummy APIC emulation."
 				"(tell your hw vendor)\n");
 		smpboot_clear_io_apic();
+		disable_ioapic_setup();
 		return -1;
 	}
 




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] x86: fully honor "nolapic" (take 2)
  2009-01-16 11:46 [PATCH] x86: fully honor "nolapic" (take 2) Jan Beulich
@ 2009-01-16 12:45 ` Ingo Molnar
  2009-01-16 13:41   ` Jan Beulich
  0 siblings, 1 reply; 7+ messages in thread
From: Ingo Molnar @ 2009-01-16 12:45 UTC (permalink / raw)
  To: Jan Beulich; +Cc: tglx, hpa, linux-kernel


* Jan Beulich <jbeulich@novell.com> wrote:

> +	if (disable_apic) {
> +#ifdef CONFIG_X86_IO_APIC
> +		disable_ioapic_setup();
> +#endif
> +		return;
> +	}

Shouldnt that #ifdef be avoided by always providing the function - just it 
is a NOP inline in the !CONFIG_X86_IO_APIC case?

	Ingo

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] x86: fully honor "nolapic" (take 2)
  2009-01-16 12:45 ` Ingo Molnar
@ 2009-01-16 13:41   ` Jan Beulich
  2009-01-16 13:42     ` Ingo Molnar
  0 siblings, 1 reply; 7+ messages in thread
From: Jan Beulich @ 2009-01-16 13:41 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: tglx, linux-kernel, hpa

>>> Ingo Molnar <mingo@elte.hu> 16.01.09 13:45 >>>
>
>* Jan Beulich <jbeulich@novell.com> wrote:
>
>> +	if (disable_apic) {
>> +#ifdef CONFIG_X86_IO_APIC
>> +		disable_ioapic_setup();
>> +#endif
>> +		return;
>> +	}
>
>Shouldnt that #ifdef be avoided by always providing the function - just it 
>is a NOP inline in the !CONFIG_X86_IO_APIC case?

That would make for a much bigger patch, since the io_apic.h doesn't
(and imo shouldn't) be included without that config option.

Jan


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] x86: fully honor "nolapic" (take 2)
  2009-01-16 13:41   ` Jan Beulich
@ 2009-01-16 13:42     ` Ingo Molnar
  2009-01-16 13:51       ` Jan Beulich
  0 siblings, 1 reply; 7+ messages in thread
From: Ingo Molnar @ 2009-01-16 13:42 UTC (permalink / raw)
  To: Jan Beulich; +Cc: tglx, linux-kernel, hpa


* Jan Beulich <jbeulich@novell.com> wrote:

> >>> Ingo Molnar <mingo@elte.hu> 16.01.09 13:45 >>>
> >
> >* Jan Beulich <jbeulich@novell.com> wrote:
> >
> >> +	if (disable_apic) {
> >> +#ifdef CONFIG_X86_IO_APIC
> >> +		disable_ioapic_setup();
> >> +#endif
> >> +		return;
> >> +	}
> >
> > Shouldnt that #ifdef be avoided by always providing the function - 
> > just it is a NOP inline in the !CONFIG_X86_IO_APIC case?
> 
> That would make for a much bigger patch, since the io_apic.h doesn't 
> (and imo shouldn't) be included without that config option.

But we are using io-apic functionality in that file, so we should include 
io_apic.h, right?

	Ingo

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] x86: fully honor "nolapic" (take 2)
  2009-01-16 13:42     ` Ingo Molnar
@ 2009-01-16 13:51       ` Jan Beulich
  2009-01-16 13:58         ` Ingo Molnar
  0 siblings, 1 reply; 7+ messages in thread
From: Jan Beulich @ 2009-01-16 13:51 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: tglx, linux-kernel, hpa

>>> Ingo Molnar <mingo@elte.hu> 16.01.09 14:42 >>>
>
>* Jan Beulich <jbeulich@novell.com> wrote:
>
>> >>> Ingo Molnar <mingo@elte.hu> 16.01.09 13:45 >>>
>> >
>> >* Jan Beulich <jbeulich@novell.com> wrote:
>> >
>> >> +	if (disable_apic) {
>> >> +#ifdef CONFIG_X86_IO_APIC
>> >> +		disable_ioapic_setup();
>> >> +#endif
>> >> +		return;
>> >> +	}
>> >
>> > Shouldnt that #ifdef be avoided by always providing the function - 
>> > just it is a NOP inline in the !CONFIG_X86_IO_APIC case?
>> 
>> That would make for a much bigger patch, since the io_apic.h doesn't 
>> (and imo shouldn't) be included without that config option.
>
>But we are using io-apic functionality in that file, so we should include 
>io_apic.h, right?

I don't generally (i.e. when !X86_IO_APIC) think so - anything accessing
stuff from io_apic.c is guarded by a similar #ifdef.

Jan


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] x86: fully honor "nolapic" (take 2)
  2009-01-16 13:51       ` Jan Beulich
@ 2009-01-16 13:58         ` Ingo Molnar
  2009-01-16 14:09           ` Jan Beulich
  0 siblings, 1 reply; 7+ messages in thread
From: Ingo Molnar @ 2009-01-16 13:58 UTC (permalink / raw)
  To: Jan Beulich; +Cc: tglx, linux-kernel, hpa


* Jan Beulich <jbeulich@novell.com> wrote:

> >>> Ingo Molnar <mingo@elte.hu> 16.01.09 14:42 >>>
> >
> >* Jan Beulich <jbeulich@novell.com> wrote:
> >
> >> >>> Ingo Molnar <mingo@elte.hu> 16.01.09 13:45 >>>
> >> >
> >> >* Jan Beulich <jbeulich@novell.com> wrote:
> >> >
> >> >> +	if (disable_apic) {
> >> >> +#ifdef CONFIG_X86_IO_APIC
> >> >> +		disable_ioapic_setup();
> >> >> +#endif
> >> >> +		return;
> >> >> +	}
> >> >
> >> > Shouldnt that #ifdef be avoided by always providing the function - 
> >> > just it is a NOP inline in the !CONFIG_X86_IO_APIC case?
> >> 
> >> That would make for a much bigger patch, since the io_apic.h doesn't 
> >> (and imo shouldn't) be included without that config option.
> >
> >But we are using io-apic functionality in that file, so we should include 
> >io_apic.h, right?
> 
> I don't generally (i.e. when !X86_IO_APIC) think so - anything accessing
> stuff from io_apic.c is guarded by a similar #ifdef.

and wrongly so - it proliferates ugly #ifdefs and sets us up for build 
failures like that. Developers cannot be expected to keep every build 
option in mind - we should provide an as homogenic and kconfig-invariant 
environment as possible.

	Ingo

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] x86: fully honor "nolapic" (take 2)
  2009-01-16 13:58         ` Ingo Molnar
@ 2009-01-16 14:09           ` Jan Beulich
  0 siblings, 0 replies; 7+ messages in thread
From: Jan Beulich @ 2009-01-16 14:09 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: tglx, linux-kernel, hpa

>>> Ingo Molnar <mingo@elte.hu> 16.01.09 14:58 >>>
>
>* Jan Beulich <jbeulich@novell.com> wrote:
>
>> >>> Ingo Molnar <mingo@elte.hu> 16.01.09 14:42 >>>
>> >
>> >* Jan Beulich <jbeulich@novell.com> wrote:
>> >
>> >> >>> Ingo Molnar <mingo@elte.hu> 16.01.09 13:45 >>>
>> >> >
>> >> >* Jan Beulich <jbeulich@novell.com> wrote:
>> >> >
>> >> >> +	if (disable_apic) {
>> >> >> +#ifdef CONFIG_X86_IO_APIC
>> >> >> +		disable_ioapic_setup();
>> >> >> +#endif
>> >> >> +		return;
>> >> >> +	}
>> >> >
>> >> > Shouldnt that #ifdef be avoided by always providing the function - 
>> >> > just it is a NOP inline in the !CONFIG_X86_IO_APIC case?
>> >> 
>> >> That would make for a much bigger patch, since the io_apic.h doesn't 
>> >> (and imo shouldn't) be included without that config option.
>> >
>> >But we are using io-apic functionality in that file, so we should include 
>> >io_apic.h, right?
>> 
>> I don't generally (i.e. when !X86_IO_APIC) think so - anything accessing
>> stuff from io_apic.c is guarded by a similar #ifdef.
>
>and wrongly so - it proliferates ugly #ifdefs and sets us up for build 
>failures like that. Developers cannot be expected to keep every build 
>option in mind - we should provide an as homogenic and kconfig-invariant 
>environment as possible.

I mostly agree here, but think that this ought to be a separate cleanup patch.

Jan


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2009-01-16 14:09 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-16 11:46 [PATCH] x86: fully honor "nolapic" (take 2) Jan Beulich
2009-01-16 12:45 ` Ingo Molnar
2009-01-16 13:41   ` Jan Beulich
2009-01-16 13:42     ` Ingo Molnar
2009-01-16 13:51       ` Jan Beulich
2009-01-16 13:58         ` Ingo Molnar
2009-01-16 14:09           ` Jan Beulich

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.