From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B11710A1F; Wed, 29 Jan 2025 01:15:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738113330; cv=none; b=Xiy19j5kjVjZdXsDPbeBrCa98bZ2iB0viLkouJ/y9nCKlTEKtBvRU7xEP7tWWvrpsGqC/Edlmm09SMwZCJ5yCyLngOVmNoak0ep5jXrtGuiUmNLVKswMEPv3Kyo8nrzKogcon2n1GS8eJBoErZMeAB4B3otJl5Y0pVFwo0Qxfug= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738113330; c=relaxed/simple; bh=LPH+rFFvj0cEdutC7LtIU0vNsmeZQG7HJPWEn8vdN3Q=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; b=WsiAJvmWWWV9zPxslo3liHXELmn86m3AOGj8uRkX6XxRZxQyTViLKcn+JekbjU93UOyo1YV9sXf3Hn+tWikYCX/Q69wzCxHGfkKTkZA3BuB8blPWVdOLQiDLm7pDsY+tAkIWfVx5+zOhZGYiJfJi7N7FNMSTyhbVzP2F0S/Ak8M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iV9OlV/a; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iV9OlV/a" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1D51C4CED3; Wed, 29 Jan 2025 01:15:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738113329; bh=LPH+rFFvj0cEdutC7LtIU0vNsmeZQG7HJPWEn8vdN3Q=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=iV9OlV/aXWEEdLHO2uvdr6xaCFhmHutsN2xpsLTRCNq2ST+c6gCBo6fi6NBvY/82X RqfudEpz9SDziEyepzeBi/dwX51b7VPEjIu2iEdjwsJ/qv6KrjptJohHIQJH1rYeKn G2md0z7KlR0jvwPODLzLE1jexGtQXpw2qeHFEtG/l+Lz7oGBvQgOA1lFEjMnpWJdnr V/gUaKp2W66i76UxCCRSkIl+3+XZb4utYI+NC3GHw6XOvsXwtUZ4c8/bYubYizdFMZ 6S/4D8RImB6QC5xpgk8TPVKMevaOwjiXqVBZL2jtzjif7CueSC6RkTXr44ZLEEthad s2vGUM3FxWKJA== Date: Tue, 28 Jan 2025 19:15:26 -0600 From: Bjorn Helgaas To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Cc: Bjorn Helgaas , =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , Roger Pau =?utf-8?B?TW9ubsOp?= , Boris Ostrovsky , xen-devel , linux-kernel@vger.kernel.org, regressions@lists.linux.dev, Felix Fietkau , Lorenzo Bianconi , Ryder Lee Subject: Re: Config space access to Mediatek MT7922 doesn't work after device reset in Xen PV dom0 (regression, Linux 6.12) Message-ID: <20250129011526.GA184585@bhelgaas> Precedence: bulk X-Mailing-List: regressions@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Jan 17, 2025 at 01:05:30PM +0100, Marek Marczykowski-Górecki wrote: > 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). Thanks for the report and for all the debugging you've already done! > 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 > 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. I'm missing something. If you get 0xffffffff, that is not the 0x0001 Vendor ID, so pci_dev_wait() should exit immediately. But the log at https://github.com/QubesOS/qubes-issues/issues/9689#issuecomment-2582927149 says it *doesn't* exit and eventually times out. And the lspci above shows ~0 data for much of the header, even though the device must be ready by then. I don't have any good ideas, but since the problem only happens with Xen, and it seems to affect more than just the Vendor ID, maybe you could instrument xen_pcibk_config_read() and see if there's something wonky going on there? > BTW, shouldn't PCI_VENDOR_ID be accessed via pci_read_config_word() > instead of pci_read_config_dword()? Per PCIe r6.0, sec 2.3.2: If Configuration RRS Software Visibility is enabled (see below): For a Configuration Read Request that includes both bytes of the Vendor ID field of a device Function's Configuration Space Header, the Root Complex must complete the Request to the host by returning a read-data value of 0001h for the Vendor ID field and all ‘1’s for any additional bytes included in the request. Since either a word (16 bit) or dword (32 bit) read includes both bytes of Vendor ID, I think either should work. We use a 32-bit read in the enumeration path, where we need both Vendor ID and Device ID, but we don't care about the Device ID here, so it probably doesn't really matter here.