Re: [PATCH] pci-host: designware: Limit value range of iATU viewport register

[Guenter Roeck]

On Thu, Feb 01, 2024 at 02:58:40PM +0000, Peter Maydell wrote:
> On Mon, 29 Jan 2024 at 06:00, Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > The latest version of qemu (v8.2.0-869-g7a1dc45af5) crashes when booting
> > the mcimx7d-sabre emulation with Linux v5.11 and later.
> >
> > qemu-system-arm: ../system/memory.c:2750: memory_region_set_alias_offset: 
> > Assertion `mr->alias' failed.
> >
> > Problem is that the Designware PCIe emulation accepts the full value range
> > for the iATU Viewport Register. However, both hardware and emulation only
> > support four inbound and four outbound viewports.
> >
> > The Linux kernel determines the number of supported viewports by writing
> > 0xff into the viewport register and reading the value back. The expected
> > value when reading the register is the highest supported viewport index.
> 
> This behaviour by the kernel seems to me to be out of spec.
> Looking at the "i.MX6 6Dual/6Quad Applications Processor Referenc
> Manual IMXDQRM" it says about the PCIE_PL_iATUVR register field
> Region_Index: "Must not be set to a value greater than 3"
> (there being 4 regions in this case).
> Plus it says elsewhere that software "should" write all-0s to
> reserved fields, and bits [7:4] are reserved in this register.
> 

Yes, I have seen that, but apparently it works with real hardware.

> > Match that code by masking the supported viewport value range when the
> > register is written. With this change, the Linux kernel reports
> >
> > imx6q-pcie 33800000.pcie: iATU: unroll F, 4 ob, 4 ib, align 0K, limit 4G
> >
> > as expected and supported.
> 
> However given this is presumably what the hardware does in this
> case where the guest does something out of spec, and we definitely
> need to do something to avoid asserting, we should take this patch.
> 

Another option might be to define some flag to enable the behavior,
in case other designware based implementations handle it differently.

At the very least the code will have to be changed to handle
situations where the register is set to a value outside the valid
range. I have no idea, though, how that should or could be handled
differently, given that we don't really know how the underlying
designware IP handles it (such as: maybe it is a mask in the IP
configuration file, and the mask for i.MX is really 0x03, not 0x0f).

On a side note, I have not been able to actually instantiate
a PCIe device behind the root bridge. If anyone knows how to do that,
please let me know.

Thanks,
Guenter