linux-kernel - RE: [PATCH] x86/smpboot: Remove 486-isms from the modern AP boot path

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: <23147db6f0c548259357babfc22a87d3@AcuMS.aculab.com>
Date:   Wed, 1 Apr 2020 10:23:55 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     "'Maciej W. Rozycki'" <macro@...ux-mips.org>,
        Thomas Gleixner <tglx@...utronix.de>
CC:     "hpa@...or.com" <hpa@...or.com>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "x86@...nel.org" <x86@...nel.org>,
        Jan Kiszka <jan.kiszka@...mens.com>,
        James Morris <jmorris@...ei.org>,
        David Howells <dhowells@...hat.com>,
        Matthew Garrett <mjg59@...gle.com>,
        Josh Boyer <jwboyer@...hat.com>,
        Zhenzhong Duan <zhenzhong.duan@...cle.com>,
        Steve Wahl <steve.wahl@....com>,
        Mike Travis <mike.travis@....com>,
        Dimitri Sivanich <dimitri.sivanich@....com>,
        "Arnd Bergmann" <arnd@...db.de>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Giovanni Gherdovich <ggherdovich@...e.cz>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Len Brown <len.brown@...el.com>,
        Kees Cook <keescook@...omium.org>,
        Martin Molnar <martin.molnar.programming@...il.com>,
        Pingfan Liu <kernelfans@...il.com>,
        "jailhouse-dev@...glegroups.com" <jailhouse-dev@...glegroups.com>
Subject: RE: [PATCH] x86/smpboot: Remove 486-isms from the modern AP boot path

From: Maciej W. Rozycki
> Sent: 01 April 2020 00:35
> On Wed, 25 Mar 2020, Thomas Gleixner wrote:
> 
> > >>@@ -1118,7 +1121,7 @@ static int do_boot_cpu(int apicid, int cpu,
> > >>struct task_struct *idle,
> > >> 		}
> > >> 	}
> > >>
> > >>-	if (x86_platform.legacy.warm_reset) {
> > >>+	if (!APIC_INTEGRATED(boot_cpu_apic_version)) {
> > >> 		/*
> > >> 		 * Cleanup possible dangling ends...
> > >> 		 */
> > >
> > > We don't support SMP on 486 and haven't for a very long time. Is there
> > > any reason to retain that code at all?
> >
> > Not that I'm aware off.
> 
>  For the record: this code is for Pentium really, covering original P5
> systems, which lacked integrated APIC, as well as P54C systems that went
> beyond dual (e.g. ALR made quad-SMP P54C systems).  They all used external
> i82489DX APICs for SMP support.  Few were ever manufactured and getting
> across one let alone running Linux might be tough these days.  I never
> managed to get one for myself, which would have been helpful for
> maintaining this code.

I remember ICL trying to get SVR4.2MP working on similar vintage hardware.
I wasn't directly involved (doing SMP sparc ethernet drivers) but ISTR
that the SMP support silicon they were using (or rather trying to use)
was basically broken.
By the time they got it (nearly) working single cpu systems were faster.

>  Even though we supported them by spec I believe we never actually ran MP
> on any 486 SMP system (Alan Cox might be able to straighten me out on
> this); none that I know of implemented the MPS even though actual hardware
> might have used the APIC architecture.  Compaq had its competing solution
> for 486 and newer SMP, actually deployed, the name of which I long forgot.
> We never supported it due to the lack of documentation combined with the
> lack of enough incentive for someone to reverse-engineer it.

I also remember one of those Compaq dual 486 boxes.
We must have has SVR4/Unixware running on it.

I suspect that any such systems would also be too slow and not have
enough memory to actually run anything recent.

OTOH there are modern 486 (like) systems than might have a reasonable
amount of memory and clock speed.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)