linux-kernel - Re: [PATCH 0/6] x86: PIRQ/ELCR-related fixes and updates

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]

Date:   Tue, 20 Jul 2021 19:12:37 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     Nikolai Zhubr <zhubr.2@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, x86@...nel.org,
        linux-pci@...r.kernel.org, linux-pm@...r.kernel.org,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/6] x86: PIRQ/ELCR-related fixes and updates

On Tue, Jul 20, 2021 at 05:27:43AM +0200, Maciej W. Rozycki wrote:
> Hi,
> 
>  In the course of adding PIRQ routing support for Nikolai's FinALi system 
> I realised we need to have some infrastructure for the indirectly accessed
> configuration space implemented by some chipsets as well as Cyrix CPUs and 
> also included with the Intel MP spec for the IMCR register via port I/O 
> space locations 0x22/0x23.  With that in place I implemented PIRQ support 
> for the Intel PCEB/ESC combined EISA southbridge using the same scheme to 
> access the relevant registers and for the final remaining Intel chipset of 
> the era, that is the i420EX.
> 
>  While at it I chose to rewrite ELCR register accesses to avoid using 
> magic numbers scattered across our code and use proper macros like with 
> the remaining PIC registers, and while at it again I noticed and fixed a 
> number of typos: s/ECLR/ELCR/.
> 
>  Since there are mechanical dependencies between the patches (except for 
> typo fixes) I chose to send them as a series rather than individually, 
> though 3/6 depends on: <https://lore.kernel.org/patchwork/patch/1452772/> 
> necessarily as well, the fate of which is currently unclear to me.
> 
>  See individual change descriptions for details.
> 
>  Nikolai: for your system only 1/6 and 2/6 are required, though you are 
> free to experiment with all the patches.  Mind that 3/6 mechanically 
> depends on the earlier change for the SIO PIRQ router referred above.  In 
> any case please use the debug patch for PCI code as well as the earlier 
> patches for your other system and send the resulting bootstrap log for 
> confirmation.
> 
>  Ideally this would be verified with PCI interrupt sharing, but for that 
> you'd have to track down one or more multifunction option cards (USB 2.0 
> interfaces with legacy 1.1 functions or serial/parallel multi-I/O cards 
> are good candidates, but of course there are more) or option devices with 
> PCI-to-PCI bridges, and then actually use some of these devices as well.  
> Any interrupt sharing will be reported, e.g.:
> 
> pci 0000:00:07.0: SIO/PIIX/ICH IRQ router [8086:7000]
> pci 0000:00:11.0: PCI INT A -> PIRQ 63, mask deb8, excl 0c20
> pci 0000:00:11.0: PCI INT A -> newirq 0
> PCI: setting IRQ 11 as level-triggered
> pci 0000:00:11.0: found PCI INT A -> IRQ 11
> pci 0000:00:11.0: sharing IRQ 11 with 0000:00:07.2
> pci 0000:02:00.0: using bridge 0000:00:11.0 INT A to get INT A
> pci 0000:00:11.0: sharing IRQ 11 with 0000:02:00.0
> pci 0000:02:01.0: using bridge 0000:00:11.0 INT B to get INT A
> pci 0000:02:02.0: using bridge 0000:00:11.0 INT C to get INT A
> pci 0000:03:00.0: using bridge 0000:00:11.0 INT A to get INT A
> pci 0000:00:11.0: sharing IRQ 11 with 0000:03:00.0
> pci 0000:04:00.0: using bridge 0000:00:11.0 INT B to get INT A
> pci 0000:04:00.3: using bridge 0000:00:11.0 INT A to get INT D
> pci 0000:00:11.0: sharing IRQ 11 with 0000:04:00.3
> pci 0000:06:05.0: using bridge 0000:00:11.0 INT D to get INT A
> pci 0000:06:08.0: using bridge 0000:00:11.0 INT C to get INT A
> pci 0000:06:08.1: using bridge 0000:00:11.0 INT D to get INT B
> pci 0000:06:08.2: using bridge 0000:00:11.0 INT A to get INT C
> pci 0000:00:11.0: sharing IRQ 11 with 0000:06:08.2
> 
> -- a lot of sharing and swizzling here. :)  You'd most definitely need: 
> <https://lore.kernel.org/patchwork/patch/1454747/> for that though, as I 
> can't imagine PCI BIOS 2.1 PIRQ routers to commonly enumerate devices 
> behind PCI-to-PCI bridges, given that they fail to cope with more complex 
> bus topologies created by option devices in the first place.

Looks nicely done but I have no ability to review or test, so I assume
the x86 folks will take care of this.

Bjorn