linux-kernel - Re: Aw: Re: Re: [PATCH] pci: mediatek: fix warning in msi.h

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:   Fri, 06 Nov 2020 09:43:58 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Frank Wunderlich <frank-w@...lic-files.de>,
        Ryder Lee <ryder.lee@...iatek.com>,
        linux-mediatek@...ts.infradead.org,
        Frank Wunderlich <linux@...web.de>,
        linux-kernel@...r.kernel.org,
        Matthias Brugger <matthias.bgg@...il.com>,
        linux-pci@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: Aw: Re:  Re: [PATCH] pci: mediatek: fix warning in msi.h

On 2020-11-05 23:00, Thomas Gleixner wrote:
> On Thu, Nov 05 2020 at 09:20, Marc Zyngier wrote:
>> On 2020-11-04 23:14, Thomas Gleixner wrote:
>>>  	/* Resource alignment requirements */
>>>  	resource_size_t (*align_resource)(struct pci_dev *dev,
>> 
>> If that's the direction of travel, we also need something like this
>> for configuration where the host bridge relies on an external MSI 
>> block
>> that uses MSI domains (boot-tested in a GICv3 guest).
> 
> Some more context would be helpful. Brain fails to decode the logic
> here.

OK, let me try again.

The MSI controller, which is the thing that deals with MSIs in the 
system
(GICv2m, GICv3-ITS, and a number of others), is optional, is not part of 
the
host bridge (it has nothing to do with PCI at all), and the bridge 
driver has
absolutely no idea  whether:

- there is something that provides MSI or not
- that something has successfully been initialised or not (which 
translates
   into an MSI domain being present or not)

This is the case for most ARM systems, and all KVM/arm guests. Booting a 
VM
without MSIs is absolutely trivial, and actually makes sense for some of 
the
smaller guests.

In these conditions, your no_msi attribute doesn't work as is: we can't 
decide
on its value at probe time without extracting all of the OF/ACPI logic 
that
deals with MSI domains from the core code, and making it available to 
the host
bridge drivers for systems that follow that model.

Using the flow you insist on requires parsing the topology twice:

- once to find out whether there is actually a MSI provider registered
   for the host bridge in order to set the no_msi flag

- once to actually be able to store the domain into the pci_bus 
structure,
   as it isn't available at probe time.

My last suggestion is to indicate to the core code that there is a 
*possible*
MSI controller available in the form of a MSI domain. This is still 
suboptimal
compared to checking the presence an MSI domain in core code (my initial
suggestion), but the fallback stuff gets in the way (though I still 
think it
can be made to work).

Anyway, this was my last attempt at addressing the problem. Most people
won't see it. The couple of drivers that require the fallback hack are
usually selected in distro kernels, and do a good job hiding the error.

         M.
-- 
Jazz is not dead. It just smells funny...