linux-kernel - Config space access to Mediatek MT7922 doesn't work after device reset in Xen PV dom0 (regression, Linux 6.12)

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>] [day] [month] [year] [list]

Message-ID: <Z4pHll_6GX7OUBzQ@mail-itl>
Date: Fri, 17 Jan 2025 13:05:30 +0100
From: Marek Marczykowski-Górecki <marmarek@...isiblethingslab.com>
To: Bjorn Helgaas <bhelgaas@...gle.com>,
	Jürgen Groß <jgross@...e.com>,
	Roger Pau Monné <roger.pau@...rix.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>
Cc: xen-devel <xen-devel@...ts.xenproject.org>,
	linux-kernel@...r.kernel.org, regressions@...ts.linux.dev,
	Felix Fietkau <nbd@....name>, Lorenzo Bianconi <lorenzo@...nel.org>,
	Ryder Lee <ryder.lee@...iatek.com>
Subject: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)

Hi,

After updating PV dom0 to Linux 6.12, The Mediatek MT7922 device reports
all 0xff when accessing its config space. This happens only after device
reset (which is also triggered when binding the device to the
xen-pciback driver).

Reproducer:

    # lspci -xs 01:00.0
    01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter
    00: c3 14 16 06 00 00 10 00 00 00 80 02 10 00 00 00
    ...
    # echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset
    # lspci -xs 01:00.0
    01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter
    00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    ...

The same operation done on Linux 6.12 running without Xen works fine.

git bisect points at:

    commit d591f6804e7e1310881c9224d72247a2b65039af
    Author: Bjorn Helgaas <bhelgaas@...gle.com>
    Date:   Tue Aug 27 18:48:46 2024 -0500

    PCI: Wait for device readiness with Configuration RRS

part of that commit:
@@ -1311,9 +1320,15 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
                        return -ENOTTY;
                }
 
-               pci_read_config_dword(dev, PCI_COMMAND, &id);
-               if (!PCI_POSSIBLE_ERROR(id))
-                       break;
+               if (root && root->config_crs_sv) {
+                       pci_read_config_dword(dev, PCI_VENDOR_ID, &id);
+                       if (!pci_bus_crs_vendor_id(id))
+                               break;
+               } else {
+                       pci_read_config_dword(dev, PCI_COMMAND, &id);
+                       if (!PCI_POSSIBLE_ERROR(id))
+                               break;
+               }
 
    
Adding some debugging, the PCI_VENDOR_ID read in pci_dev_wait() returns
initially 0xffffffff. If I extend the condition with
"&& !PCI_POSSIBLE_ERROR(id)", then the issue disappear. But reading the
patch description, it would break VF.
I'm not sure where the issue is, but given it breaks only when running
with Xen, I guess something is wrong with "Configuration RRS Software
Visibility" in that case.

BTW, shouldn't PCI_VENDOR_ID be accessed via pci_read_config_word()
instead of pci_read_config_dword()?

I'm also CC-ing MT76 driver maintainers in case it turns out to be
device-specific issue, not a generic one.

Initially reported at https://github.com/QubesOS/qubes-issues/issues/9689

#regzbot introduced: d591f6804e7e1310881c9224d72247a2b65039af

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)