linux-kernel - Re: [RFC PATCH v2 13/21] irqchip: riscv-intc: Add ACPI support for AIA

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:   Mon, 06 Nov 2023 11:35:27 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Bjorn Helgaas <helgaas@...nel.org>
Cc:     Sunil V L <sunilvl@...tanamicro.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-riscv@...ts.infradead.org, linux-acpi@...r.kernel.org,
        linux-pci@...r.kernel.org, linux-serial@...r.kernel.org,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Anup Patel <anup@...infault.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Conor Dooley <conor.dooley@...rochip.com>,
        Andrew Jones <ajones@...tanamicro.com>,
        Atish Kumar Patra <atishp@...osinc.com>,
        Haibo Xu <haibo1.xu@...el.com>
Subject: Re: [RFC PATCH v2 13/21] irqchip: riscv-intc: Add ACPI support for AIA

On Fri, 27 Oct 2023 18:45:38 +0100,
Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> On Thu, Oct 26 2023 at 11:51, Bjorn Helgaas wrote:
> > On Thu, Oct 26, 2023 at 01:53:36AM +0530, Sunil V L wrote:
> >> The RINTC subtype structure in MADT also has information about other
> >> interrupt controllers like MMIO. So, save those information and provide
> >> interfaces to retrieve them when required by corresponding drivers.
> >
> >> @@ -218,7 +306,19 @@ static int __init riscv_intc_acpi_init(union acpi_subtable_headers *header,
> >
> >> +	 * MSI controller (IMSIC) in RISC-V is optional. So, unless
> >> +	 * IMSIC is discovered, set system wide MSI support as
> >> +	 * unsupported. Once IMSIC is probed, MSI support will be set.
> >> +	 */
> >> +	pci_no_msi();
> >
> > It doesn't seem like we should have to tell the PCI core about
> > functionality we *don't* have.
> >
> > I would think IMSIC would be detected before enumerating PCI devices
> > that might use it, and if we *haven't* found an IMSIC by the time we
> > get to pci_register_host_bridge(), would/should we set
> > PCI_BUS_FLAGS_NO_MSI there?
> >
> > I see Thomas is cc'd; he'd have better insight.
> 
> I was not really involved with this bus and MSI domain logic. Marc
> should know. CC'ed.

The canonical way of doing this is by the platform expressing that
there is no linkage between the PCIe RC and the MSI controller.  If
there is no MSI domain associated with the RC, then by extension the
endpoints don't get one either.

There are additional quirks linked to the msi_domain host bridge
property, allowing the host bridge driver to indicate that it isn't in
charge of MSIs, but that a third party may provide it (in which case a
MSI irq domain will be associated with it).

In any case, slapping a pci_no_msi() call in an irqchip driver is
gross and most probably a sign that this is going in the wrong
direction, specially as this is platform-wide.

The only cases I'd expect this function to be called are:

- Platform or firmware explicitly disallowing MSIs
- pci=nomsi on the command line

none of which are the business of an irqchip driver.

HTH,

	M.

-- 
Without deviation from the norm, progress is not possible.