linux-kernel - Re: [PATCH] x86: let MPS support selectable

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: <alpine.LFD.1.10.0806191350530.3040@localhost.localdomain>
Date:	Thu, 19 Jun 2008 14:03:56 -0400 (EDT)
From:	Len Brown <lenb@...nel.org>
To:	Yinghai Lu <yhlu.kernel@...il.com>
Cc:	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Daniel Exner <dex@...gonslave.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: let MPS support selectable

On Thu, 19 Jun 2008, Yinghai Lu wrote:

> On Thu, Jun 19, 2008 at 8:10 AM, Maciej W. Rozycki <macro@...ux-mips.org> wrote:
> > On Thu, 19 Jun 2008, Yinghai Lu wrote:
> >
> >> @@ -233,6 +233,19 @@ config SMP
> >>
> >>         If you don't know what to do here, say N.
> >>
> >> +config X86_FIND_SMP_CONFIG
> >> +     def_bool y
> >> +     depends on X86_MPPARSE || X86_VOYAGER || X86_VISWS
> >> +     depends on X86_32
> >> +
> >> +config X86_MPPARSE
> >> +     def_bool y
> >> +     bool "Enable MPS table"
> >> +     depends on (X86_32 && (X86_LOCAL_APIC && !X86_VISWS)) || X86_64
> >> +     help
> >> +       For old smp systems that do not have proper acpi support. Newer systems
> >> +       (esp with 64bit cpus) with acpi support, MADT and DSDT will override it
> >> +
> >>  choice
> >>       prompt "Subarchitecture Type"
> >>       default X86_PC
> >
> >  First of all you want to make sure at least one of ACPI and X86_MPPARSE
> > is enabled if X86_LOCAL_APIC or you risk a known-broken kernel
> > configuration, e.g. SMP which has no slightest chance to work.
> >
> >  Personally I'd be happy to see CONFIG_ACPI_BOOT we used to have at one
> > point back just so that you can use ACPI tables to run an SMP system
> > without the need to pull all the power management stuff.  Useful if the MP
> > table is broken beyond recovery.  I am assuming it has been removed for a
> > reason though.
> 
> thanks. will try to add CONFIG_ACPI_BOOT...

NAK.

CONFIG_ACPI_BOOT was removed because it was fundamentally ill-conceived
and created a situation which was not only more difficult to maintain
but also didn't work on most machines.
ACPI interrupt configuration depends on the ACPI interpreter, so to boot
properly and configure interrupts with ACPI, you need 90% of the kernel's
ACPI code present anyway.
The other 10% are the Linux policy drivers, fan, processor, etc, and those
can be already be de-configured one by one if desired.

If you want to use ACPI just for enumerating processors, ie to see
the HT that MPS usually doesn't include, you can boot with "acpi=ht",
which will not enter ACPI mode or use ACPI for anything else.
We used to have a compile option for this, but most people who used
it did so by mistake and then complained that all sorts of things,
(starting with the power button) didn't work, so it was removed.

I don't think we should be going out of our way to enhance MPS support.
There probably isn't a single system shipped in this century that has MPS
that doesen't have ACPI, while there are millions of systems that
have ACPI and no MPS.  MPS is going away, and making
it a config option prepares us for the day when we completely
don't care about it any more.

However, I think that adding CONFIG_MPS before removing ACPI's
depencency on mpparse.c has all risk and no value.

thanks,
-Len

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