On Sat, May 17, 2025 at 05:14:59PM +0000, Chathura Rajapaksha wrote: > On Fri, May 16, 2025 at 2:35 PM Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > > By PCI bus error, I was referring to AER-reported uncorrectable errors. > > > For example: > > > pcieport 0000:c0:01.1: PCIe Bus Error: severity=Uncorrected (Fatal), type=Transaction Layer, (Requester ID) > > > pcieport 0000:c0:01.1: device [1022:1483] error status/mask=00004000/07a10000 > > > pcieport 0000:c0:01.1: [14] CmpltTO (First) > > > > That's sure looks like a device bug. You should not ever get time out > > for a config space read. > > Just to clarify, the above error was triggered by a write to the > configuration space. In fact, all the errors we have observed so far > were triggered by writes to unassigned PCI config space regions. Yuk, devices really shouldn't refuse to respond to writes or reads :( > So far, we have seen this issue on five PCIe devices across GPU and > storage classes from two different vendors. Ugh, that's awful. > > Alternatively you could handle this in qemu by sanitizing the config > > space.. > > While it's possible to address this issue for QEMU-KVM guests by > modifying QEMU, PCIe devices can also be assigned directly to > user-space applications such as DPDK via VFIO. We thought addressing > this at the VFIO driver level would help mitigate the issue in a > broader context beyond virtualized environments. VFIO can probably already trigger command timeouts if it tries hard enough, as long as it is a contained AER I don't see that the kernel *needs* to prevent it.. For virtualization I really do expect that any serious user will be tightly controlling the config space and maybe this finding just supports that qemu needs to be enhanced to have more configurability here. It certainly is easier to add an option to qemu to make it block any address not in a cap chain than to add a bunch of PCI ID tables and detection to the kernel.. Jason
