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

From: Marc Zyngier
Date: Fri Nov 06 2020 - 04:44:04 EST


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...