Date:   Thu, 2 Apr 2020 00:32:30 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@...ux-mips.org>
To:     Andrew Cooper <andrew.cooper3@...rix.com>
cc:     Thomas Gleixner <tglx@...utronix.de>, hpa@...or.com,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        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
Subject: Re: [PATCH] x86/smpboot: Remove 486-isms from the modern AP boot
 path

On Wed, 1 Apr 2020, Andrew Cooper wrote:

> >  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 chose "486-ism" based on what the MP spec said about external vs
> integrated Local APICs.  I can't claim to have any experience of those days.

 The spec is quite clear about the use of discrete APICs actually:

"5.1 Discrete APIC Configurations

"   Figure 5-1 shows the default configuration for systems that use the 
    discrete 82489 APIC.  The Intel486 processor is shown as an example; 
    however, this configuration can also employ Pentium processors.  In 
    Pentium processor systems, PRST is connected to INIT instead of to 
    RESET."

:)  And if in the way the internal local APIC in P54C processors can be
permanently disabled (causing it not to be reported in CPUID flags) via a 
reset strap, e.g. to support an unusual configuration.

 As I recall the integrated APIC would in principle support SMP configs 
beyond dual (the inter-APIC bus was serial at the time and supported 15 
APIC IDs with the P54C), but at the time the P54C processor was released 
the only compatible I/O APICs were available as a part of Intel PCI south 
bridges (the 82375EB/SB ESC and the 82379AB SIO.A).  Those chips were not 
necessarily compatible with whatever custom chipset was developed to 
support e.g. a quad-SMP P54C system.  Or there were political reasons 
preventing them from being used.

 Then the 82489DX used an incompatible protocol (supporting 254 APIC IDs 
among others, and as I recall the serial bus had a different number of 
wires even), so it couldn't be mixed with integrated local APICs.  That's 
why discrete APICs were sometimes used even with P54C processors.

 And the 82093AA standalone I/O APIC was only introduced a few years 
later, along with the Intel HX (Triton II) SMP chipset.  I still have a 
nice working machine equipped with this chipset and dual P55C processors 
@233MHz.  Even the original CPU fans are going strong. :)  Its MP table is 
however buggy and difficult to work with if the I/O APIC is to be used, 
especially if PCI-PCI bridges are involved (there's none onboard, but you 
can have these easily in multiple quantities on option cards nowadays).

  Maciej

Powered by blists - more mailing lists