Devices behind a non-ACS switch are assigned different iommu-groups

Devices behind a non-ACS switch are assigned different iommu-groups

[Ilya Lesokhin]

Hi,
I was testing devices assignment behind a non-ACS switch and to my surprise=
,
Devices connected to different ports were assigned different iommu-groups.

The reason for this behavior is that pci_acs_enabled(...) considers the swi=
tch=20
Upstream port to have ACS enabled.
http://elixir.free-electrons.com/linux/v4.13.1/source/drivers/pci/pci.c#L29=
14
(the upstream port is not a multifunction device).

I'm not sure what the correct solution is but I believe, the upstream port
Shouldn't be considered in pci_acs_path_enable(...).

Thanks,
Ilya

Re: Devices behind a non-ACS switch are assigned different iommu-groups

[Alex Williamson]

On Sun, 29 Oct 2017 07:56:52 +0000
Ilya Lesokhin <ilyal@mellanox.com> wrote:

> Hi,
> I was testing devices assignment behind a non-ACS switch and to my surprise,
> Devices connected to different ports were assigned different iommu-groups.
> 
> The reason for this behavior is that pci_acs_enabled(...) considers the switch 
> Upstream port to have ACS enabled.
> http://elixir.free-electrons.com/linux/v4.13.1/source/drivers/pci/pci.c#L2914
> (the upstream port is not a multifunction device).
> 
> I'm not sure what the correct solution is but I believe, the upstream port
> Shouldn't be considered in pci_acs_path_enable(...).

Yes, this seems like a bug.  We should fix it, but we're likely to make
some people unhappy by doing so :-\  My guess it that this works
correctly if the switch enumerates downstream ports as separate
functions within the same slot, but fails if the downstream ports are
exposed as separate slots.  We like to assume that separate slots are
isolated, but of course they're all within the internal implementation
of the switch here.  Patches welcome, otherwise I'll try to look at it
soon.  Thanks,

Alex