linux-kernel - Re: [RFC 1/2] arm64: PCI: Allow use arch-specific pci sysdata

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: <CAK8P3a3qj=9KEN=X2uGCq0TrOGpyPw1Gwipmn=Gqx4LAfqUEDQ@mail.gmail.com>
Date:   Sat, 20 Mar 2021 13:54:50 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     Boqun Feng <boqun.feng@...il.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux on Hyper-V List <linux-hyperv@...r.kernel.org>,
        linux-pci <linux-pci@...r.kernel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        "K. Y. Srinivasan" <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Wei Liu <wei.liu@...nel.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Rob Herring <robh@...nel.org>, Clint Sbisa <csbisa@...zon.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Sunil Muthuswamy <sunilmut@...rosoft.com>,
        Marc Zyngier <maz@...nel.org>
Subject: Re: [RFC 1/2] arm64: PCI: Allow use arch-specific pci sysdata

On Fri, Mar 19, 2021 at 10:14 PM Bjorn Helgaas <helgaas@...nel.org> wrote:
> > However, for a virtualized PCI bus, there might be no enough data in of
> > or acpi table to create a pci_config_window. This is similar to the case
> > where CONFIG_PCI_DOMAINS_GENERIC=n, IOW, architectures use their own
> > structure for sysdata, so no apci table lookup is required.
> >
> > In order to enable Hyper-V's virtual PCI (which doesn't have acpi table
> > entry for PCI) on ARM64 (which selects CONFIG_PCI_DOMAINS_GENERIC), we
> > introduce arch-specific pci sysdata (similar to the one for x86) for
> > ARM64, and allow the core PCI code to detect the type of sysdata at the
> > runtime. The latter is achieved by adding a pci_ops::use_arch_sysdata
> > field.
> >
> > Originally-by: Sunil Muthuswamy <sunilmut@...rosoft.com>
> > Signed-off-by: Boqun Feng (Microsoft) <boqun.feng@...il.com>
> > ---
> >  arch/arm64/include/asm/pci.h | 29 +++++++++++++++++++++++++++++
> >  arch/arm64/kernel/pci.c      | 15 ++++++++++++---
> >  include/linux/pci.h          |  3 +++
> >  3 files changed, 44 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> > index b33ca260e3c9..dade061a0658 100644
> > --- a/arch/arm64/include/asm/pci.h
> > +++ b/arch/arm64/include/asm/pci.h
> > @@ -22,6 +22,16 @@
> >
> >  extern int isa_dma_bridge_buggy;
> >
> > +struct pci_sysdata {
> > +     int domain;     /* PCI domain */
> > +     int node;       /* NUMA Node */
> > +#ifdef CONFIG_ACPI
> > +     struct acpi_device *companion;  /* ACPI companion device */
> > +#endif
> > +#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
> > +     void *fwnode;                   /* IRQ domain for MSI assignment */
> > +#endif
> > +};
>
> Our PCI domain code is really a mess (mostly my fault) and I hate to
> make it even more complicated by adding more switches, e.g.,
> ->use_arch_sysdata.
>
> I think the design problem is that PCI host bridge drivers should
> supply the PCI domain up front instead of having callbacks to extract
> it.
>
> We could put "int domain_nr" in struct pci_host_bridge, and the arch
> code or host bridge driver (pcibios_init_hw(), *_pcie_probe(), VMD,
> HV, etc) could fill in pci_host_bridge.domain_nr before calling
> pci_scan_root_bus_bridge() or pci_host_probe().
>
> Then maybe we could get rid of pci_bus_find_domain_nr() and some of
> the needlessly arch-specific implementations of pci_domain_nr().
> I think we likely could get rid of CONFIG_PCI_DOMAINS_GENERIC, too,
> eventually.

Agreed. I actually still have a (not really tested) patch series to clean up
the pci host bridge registration, and this should make this a lot easier
to add on top.

I should dig that out of my backlog and post for review.

         Arnd