linux-kernel - Re: [PATCH] x86: update_mptable need pci

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: <20090516102555.GA6261@elte.hu>
Date:	Sat, 16 May 2009 12:25:55 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-pci@...r.kernel.org
Subject: Re: [PATCH] x86: update_mptable need pci_routeirq


* Bjorn Helgaas <bjorn.helgaas@...com> wrote:

> On Friday 15 May 2009 04:03:49 pm Yinghai Lu wrote:
> > Bjorn Helgaas wrote:
> > > On Friday 15 May 2009 03:13:20 pm Yinghai Lu wrote:
> > >> Bjorn Helgaas wrote:
> > >>> On Friday 15 May 2009 01:51:56 pm Yinghai Lu wrote:
> > >>>> to get all device irq routing and save them
> > >>> This changelog isn't really enough for me to understand
> > >>> what's going on.
> > >>>
> > >>>> Index: linux-2.6/arch/x86/kernel/mpparse.c
> > >>>> ===================================================================
> > >>>> --- linux-2.6.orig/arch/x86/kernel/mpparse.c
> > >>>> +++ linux-2.6/arch/x86/kernel/mpparse.c
> > >>>> @@ -17,6 +17,7 @@
> > >>>>  #include <linux/acpi.h>
> > >>>>  #include <linux/module.h>
> > >>>>  #include <linux/smp.h>
> > >>>> +#include <linux/pci.h>
> > >>>>  
> > >>>>  #include <asm/mtrr.h>
> > >>>>  #include <asm/mpspec.h>
> > >>>> @@ -961,6 +962,7 @@ static int __initdata enable_update_mpta
> > >>>>  static int __init update_mptable_setup(char *str)
> > >>>>  {
> > >>>>  	enable_update_mptable = 1;
> > >>>> +	pci_routeirq = 1;
> > >>> I hate to see new uses of pci_routeirq.  It'd be nice to remove it
> > >>> completely someday.  But maybe it can't be helped.
> > >>>
> > >>>>  	return 0;
> > >>>>  }
> > >>>>  early_param("update_mptable", update_mptable_setup);
> > >>> "update_mptable" is apparently a boot option, but it's not mentioned
> > >>> in Documentation/kernel-parameters.txt.  Is this some sort of debug
> > >>> code or BIOS-writer's helper?  Same with "alloc_mptable".  Why do
> > >>> we have this stuff?
> > >>>
> > >> 1. kexec path: after acpi kernel and use kexec to load kerenl with mptable support only or acpi=off
> > >> 2. help to BIOS engineer to understand how to set mptable and irq routing setup by chipset.
> > >>    esp system have several cards and there is bridge in those cards.
> > ...
> > > Is (1) common enough to worry about?  What OSes don't have ACPI
> > > support?  What advantage is there to using "acpi=off"?
> > ...
> > 
> > some one want to disable acpi, because acpid is using 100%...
> 
> I'd rather fix the problem with acpid than make it easier to use 
> "acpi=off".

Well, acpi=off is frequently used. Besides of that, there's a design 
and future-proof-ness issue as well: having a correct mptable is 
good in sense of not having all our collective eggs in the ACPI 
basket. ACPI also has IP attached and there are vendors who are 
loathe to use it for one reason or another.

So as long as Yinghai is willing to maintain this path and is 
willing to keep it correct, and as long as we _have_ an acpi=off 
option in the upstream kernel it makes sense to make the kexec 
environment as correct and inclusive as possible.

acpid looping should of course be fixed separately. Almost all 
distros ship with acpi enabled so there's no shortage of bugs being 
reported, and there's no need to artificially make it harder for 
people to not use acpi if they so choose.

	Ingo
--
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/