[{"id":3678092,"web_url":"http://patchwork.ozlabs.org/comment/3678092/","msgid":"","list_archive_url":null,"date":"2026-04-16T11:08:03","subject":"Re: [PATCH] PCI: Update saved_config_space upon resource\n assignment","submitter":{"id":83553,"url":"http://patchwork.ozlabs.org/api/people/83553/","name":"Ilpo Järvinen","email":"ilpo.jarvinen@linux.intel.com"},"content":"On Wed, 15 Apr 2026, Lukas Wunner wrote:\n\n> Bernd reports passthrough failure of a Digital Devices Cine S2 V6 DVB\n> adapter plugged into an ASRock X570S PG Riptide board with BIOS version\n> P5.41 (09/07/2023):\n> \n> ddbridge 0000:05:00.0: detected Digital Devices Cine S2 V6 DVB adapter\n> ddbridge 0000:05:00.0: cannot read registers\n> ddbridge 0000:05:00.0: fail\n> \n> BIOS assigns an incorrect BAR to the DVB adapter which doesn't fit into\n> the upstream bridge window. The kernel corrects the BAR assignment:\n> \n> pci 0000:07:00.0: BAR 0 [mem 0xfffffffffc500000-0xfffffffffc50ffff 64bit]: can't claim; no compatible bridge window\n> pci 0000:07:00.0: BAR 0 [mem 0xfc500000-0xfc50ffff 64bit]: assigned\n> \n> Correction of the BAR assignment happens in an x86-specific fs_initcall,\n> pcibios_assign_resources(), after device enumeration in a subsys_initcall.\n> This order was introduced at the behest of Linus in 2004:\n> \n> https://git.kernel.org/tglx/history/c/a06a30144bbc\n> \n> No other architecture performs such a late BAR correction.\n> \n> Bernd bisected the issue to commit a2f1e22390ac (\"PCI/ERR: Ensure error\n> recoverability at all times\"), but it only occurs in the absence of commit\n> 4d4c10f763d7 (\"PCI: Explicitly put devices into D0 when initializing\").\n> This combination exists in stable kernel v6.12.70, but not in mainline,\n> hence Bernd cannot reproduce the issue with mainline.\n> \n> Since a2f1e22390ac, config space is saved on enumeration, prior to BAR\n> correction. Upon passthrough, the corrected BAR is overwritten with the\n> incorrect saved value by:\n> \n> vfio_pci_core_register_device()\n> vfio_pci_set_power_state()\n> pci_restore_state()\n> \n> But only if the device's current_state is PCI_UNKNOWN, as it was prior to\n> commit 4d4c10f763d7. Since the commit, it is PCI_D0, which changes the\n> behavior of vfio_pci_set_power_state() to no longer restore the state\n> without saving it first.\n> \n> Alexandre is reporting the same issue as Bernd, but in his case, mainline\n> is affected as well. The difference is that on Alexandre's system, the\n> host kernel binds a driver to the device which is unbound prior to\n> passthrough, whereas on Bernd's system no driver gets bound by the host\n> kernel.\n> \n> Unbinding sets current_state to PCI_UNKNOWN in pci_device_remove(), so\n> when vfio-pci is subsequently bound to the device, pci_restore_state() is\n> once again called without invoking pci_save_state() first.\n> \n> To robustly fix the issue, always update saved_config_space upon resource\n> assignment.\n> \n> Reported-by: Bernd Schumacher \n> Tested-by: Bernd Schumacher \n> Closes: https://lore.kernel.org/r/acfZrlP0Ua_5D3U4@eldamar.lan/\n> Reported-by: Alexandre N. \n> Tested-by: Alexandre N. \n> Closes: https://lore.kernel.org/r/dd3c3358-de0f-4a56-9c81-04aceaab4058@mailo.com/\n> Fixes: a2f1e22390ac (\"PCI/ERR: Ensure error recoverability at all times\")\n> Signed-off-by: Lukas Wunner \n> Cc: stable@vger.kernel.org # v6.12+\n> ---\n> drivers/pci/setup-res.c | 2 ++\n> 1 file changed, 2 insertions(+)\n> \n> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c\n> index e5fcadf..1769ba9 100644\n> --- a/drivers/pci/setup-res.c\n> +++ b/drivers/pci/setup-res.c\n> @@ -102,6 +102,7 @@ static void pci_std_update_resource(struct pci_dev *dev, int resno)\n> \t}\n> \n> \tpci_write_config_dword(dev, reg, new);\n> +\tdev->saved_config_space[reg / 4] = new;\n> \tpci_read_config_dword(dev, reg, &check);\n> \n> \tif ((new ^ check) & mask) {\n> @@ -112,6 +113,7 @@ static void pci_std_update_resource(struct pci_dev *dev, int resno)\n> \tif (res->flags & IORESOURCE_MEM_64) {\n> \t\tnew = region.start >> 16 >> 16;\n> \t\tpci_write_config_dword(dev, reg + 4, new);\n> +\t\tdev->saved_config_space[(reg + 4) / 4] = new;\n> \t\tpci_read_config_dword(dev, reg + 4, &check);\n> \t\tif (check != new) {\n> \t\t\tpci_err(dev, \"%s: error updating (high %#010x != %#010x)\\n\",\n\nHi Lukas,\n\nI'm wondering if there's something that makes this problem specific to \nonly standard BARs?\n\nCan other resources, namely IOV resources or bridge windows, similarly be \nupdated \"too late\" and not get correctly updated into the saved config \nspace?","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=PXURT7Y1;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-52595-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=\"PXURT7Y1\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=198.175.65.19","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.intel.com"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxFcQ3m1Nz1yG9\n\tfor ; Thu, 16 Apr 2026 21:08:22 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 07A43304F222\n\tfor ; Thu, 16 Apr 2026 11:08:19 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id AF6D53A6EF8;\n\tThu, 16 Apr 2026 11:08:15 +0000 (UTC)","from mgamail.intel.com (mgamail.intel.com [198.175.65.19])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 69F9D3939CC\n\tfor ; Thu, 16 Apr 2026 11:08:13 +0000 (UTC)","from fmviesa001.fm.intel.com ([10.60.135.141])\n by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 16 Apr 2026 04:08:13 -0700","from rvuia-mobl.ger.corp.intel.com (HELO localhost)\n ([10.245.245.12])\n by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 16 Apr 2026 04:08:08 -0700"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776337695; cv=none;\n b=H9KPajyuESJl2vOn0BuQJZrfzrixb3Ke0nBVWCJPKPSTZwWIIKhazpOPN0G5o+U4/qLuwgruTvGVRTjPEVu2LAhJPJ/czXFoxr0bakH4ZTZNnbPWMvvqI3vS6+wOHRKLFAVJh6mVz71tILajHX6ln/A9rLhFqcpUATE3UlSdeb0=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776337695; c=relaxed/simple;\n\tbh=DQwkVMKOwzWi4l0FJfWXhOkm0YP9JxkkBkUKeGamdWw=;\n\th=From:Date:To:cc:Subject:In-Reply-To:Message-ID:References:\n\t MIME-Version:Content-Type;\n b=EnpsvGuU/l2rTCXR9q/LtKwSHTl1Ls+aXqvrFk3ol7XJIHkI4kEaE2JFdrSauA2rFEfgci8br9T/mR1BMb6nXqmziujWrD6KmiOj3LkU6pWh0HnSCdDhnuCrULCHgofjB29lPZyGmLlf2wlDDNhGGMQtHXLwNZkwwh+LEcYCpfU=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com;\n spf=pass smtp.mailfrom=linux.intel.com;\n dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=PXURT7Y1; arc=none smtp.client-ip=198.175.65.19","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1776337693; x=1807873693;\n h=from:date:to:cc:subject:in-reply-to:message-id:\n references:mime-version;\n bh=DQwkVMKOwzWi4l0FJfWXhOkm0YP9JxkkBkUKeGamdWw=;\n b=PXURT7Y19qrDCl7G5popjXRKBS0D9TY3UjIhhBrfX3uSfex3QFFpdXdv\n 32ayHdL3R58ErmACau11VQPX0CATRcoyR2Rzh9eeY2ZCyN9gE2Rd8/3Tz\n F/8MZ6PvX3qiibIVrp4W9iJpIBtyRORGm9LW7Ks4Kv0t006d0C37/Pm/c\n CCrP9vlxObXSPOEM/jU3fVptRA00RBJlCmpXJwIKYygX586csd4Tl4uya\n PNNeE8J/LjdLqWTbaRbzhKohkSyGmYNaemwejRwfbAQtTL8icalM8L2Ka\n DHMLNlvXXFWAwkV/HriU5dxui4BwaJHhnfpd+jADMFqK749iEDY/1Hha6\n Q==;","X-CSE-ConnectionGUID":["hijzm2N3RXCdD2d8A+Bytw==","VMPYZ+UnSoyK4m7o5IYZeQ=="],"X-CSE-MsgGUID":["GL130ZBRRlmcqPb5zsLZ7A==","+Ihv2uYNTfWXaqpvKGyipw=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11760\"; a=\"77240876\"","E=Sophos;i=\"6.23,181,1770624000\";\n d=\"scan'208\";a=\"77240876\"","E=Sophos;i=\"6.23,181,1770624000\";\n d=\"scan'208\";a=\"254158489\""],"X-ExtLoop1":"1","From":"=?utf-8?q?Ilpo_J=C3=A4rvinen?= ","Date":"Thu, 16 Apr 2026 14:08:03 +0300 (EEST)","To":"Lukas Wunner ","cc":"Bjorn Helgaas , Bernd Schumacher ,\n \"Alexandre N.\" ,\n Salvatore Bonaccorso , 1131025@bugs.debian.org,\n Uwe Kleine-Koenig ,\n \"Rafael J. Wysocki\" ,\n Mario Limonciello ,\n Alex Williamson , regressions@lists.linux.dev,\n linux-pci@vger.kernel.org","Subject":"Re: [PATCH] PCI: Update saved_config_space upon resource\n assignment","In-Reply-To":"\n ","Message-ID":"","References":"\n ","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII"}},{"id":3678103,"web_url":"http://patchwork.ozlabs.org/comment/3678103/","msgid":"","list_archive_url":null,"date":"2026-04-16T11:28:33","subject":"Re: [PATCH] PCI: Update saved_config_space upon resource assignment","submitter":{"id":68499,"url":"http://patchwork.ozlabs.org/api/people/68499/","name":"Lukas Wunner","email":"lukas@wunner.de"},"content":"On Thu, Apr 16, 2026 at 02:08:03PM +0300, Ilpo Järvinen wrote:\n> On Wed, 15 Apr 2026, Lukas Wunner wrote:\n> > Bernd reports passthrough failure of a Digital Devices Cine S2 V6 DVB\n> > adapter plugged into an ASRock X570S PG Riptide board with BIOS version\n> > P5.41 (09/07/2023):\n[...]\n> > Since a2f1e22390ac, config space is saved on enumeration, prior to BAR\n> > correction. Upon passthrough, the corrected BAR is overwritten with the\n> > incorrect saved value by:\n> \n> I'm wondering if there's something that makes this problem specific to \n> only standard BARs?\n> \n> Can other resources, namely IOV resources or bridge windows, similarly be \n> updated \"too late\" and not get correctly updated into the saved config \n> space?\n\nIOV registers are not saved, they're reconstructed from pci_dev->resource[]:\n\npci_restore_iov_state()\n sriov_restore_state()\n pci_update_resource()\n pci_iov_update_resource()\n\nBridge windows are saved when portdrv probes (see call to pci_save_state()\nin pcie_portdrv_probe()) and that happens after the fs_initcall() because\nportdrv is registered from a device_initcall(). So those should be fine\nas well.\n\n(FWIW sashiko also flagged the bridge windows not getting saved as an\n(alleged) problem.)\n\nThanks for taking a look!\n\nLukas","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c15:e001:75::12fc:5321; helo=sin.lore.kernel.org;\n envelope-from=linux-pci+bounces-52611-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=83.223.95.204","smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=wunner.de","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=wunner.de"],"Received":["from sin.lore.kernel.org (sin.lore.kernel.org\n [IPv6:2600:3c15:e001:75::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxG434pQ4z1yCv\n\tfor ; Thu, 16 Apr 2026 21:28:51 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 1CFAC300C7DA\n\tfor ; Thu, 16 Apr 2026 11:28:49 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id D7A9A3A63FE;\n\tThu, 16 Apr 2026 11:28:45 +0000 (UTC)","from mailout1.hostsharing.net (mailout1.hostsharing.net\n [83.223.95.204])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id DC9553A7F48\n\tfor ; Thu, 16 Apr 2026 11:28:40 +0000 (UTC)","from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384\n\t client-signature ECDSA (secp384r1) client-digest SHA384)\n\t(Client CN \"*.hostsharing.net\",\n Issuer \"GlobalSign GCC R6 AlphaSSL CA 2025\" (verified OK))\n\tby mailout1.hostsharing.net (Postfix) with ESMTPS id 6ADBF384;\n\tThu, 16 Apr 2026 13:28:33 +0200 (CEST)","by h08.hostsharing.net (Postfix, from userid 100393)\n\tid 664AF6010CEA; Thu, 16 Apr 2026 13:28:33 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776338925; cv=none;\n b=QX2Ua6gsAWOAeo6tsa+/ikRCs8hBpTQLUYaC5Ni/FPXBea6QO/MrF3at6Kg1wjeGnTioM9Z9eS/d9sRgYH5ctZ0FlKK2F5cHanN70XzwxRink5jPlgeAE6dkJYbyO2O9I4WH/qrmdn/3wsTCIsED2G/6SOe22J6O21iMFdFdG10=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776338925; c=relaxed/simple;\n\tbh=XI5DiIWGv3ZHR4ELQt4TG1wvoKDdF3J5NDKnJ9BMuo0=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=Kx+bal8d+yF4/laV3nmFnO1waws7EOwvuGPhgR2roNvBXFE+ChLtsjiUnAUQijX1KCZD1iOy41ukWU8e9IYhxY5k0CwTt1JsoMzlKQX1Va4ya8jpfeskUjQhCgq5WAal56q0Km8pD3wpyjTRbwUidNYZUBqtafYAw4cKCCv0LpY=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=wunner.de;\n spf=pass smtp.mailfrom=wunner.de; arc=none smtp.client-ip=83.223.95.204","Date":"Thu, 16 Apr 2026 13:28:33 +0200","From":"Lukas Wunner ","To":"Ilpo =?iso-8859-1?q?J=E4rvinen?= ","Cc":"Bjorn Helgaas , Bernd Schumacher ,\n\t\"Alexandre N.\" ,\n\tSalvatore Bonaccorso , 1131025@bugs.debian.org,\n\tUwe Kleine-Koenig ,\n\t\"Rafael J. Wysocki\" ,\n\tMario Limonciello ,\n\tAlex Williamson , regressions@lists.linux.dev,\n\tlinux-pci@vger.kernel.org","Subject":"Re: [PATCH] PCI: Update saved_config_space upon resource assignment","Message-ID":"","References":"\n \n ","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":""}},{"id":3678125,"web_url":"http://patchwork.ozlabs.org/comment/3678125/","msgid":"<9fcb46ff-56d2-1504-11a1-ad8449c80b2d@linux.intel.com>","list_archive_url":null,"date":"2026-04-16T12:16:08","subject":"Re: [PATCH] PCI: Update saved_config_space upon resource\n assignment","submitter":{"id":83553,"url":"http://patchwork.ozlabs.org/api/people/83553/","name":"Ilpo Järvinen","email":"ilpo.jarvinen@linux.intel.com"},"content":"On Thu, 16 Apr 2026, Lukas Wunner wrote:\n\n> On Thu, Apr 16, 2026 at 02:08:03PM +0300, Ilpo Järvinen wrote:\n> > On Wed, 15 Apr 2026, Lukas Wunner wrote:\n> > > Bernd reports passthrough failure of a Digital Devices Cine S2 V6 DVB\n> > > adapter plugged into an ASRock X570S PG Riptide board with BIOS version\n> > > P5.41 (09/07/2023):\n> [...]\n> > > Since a2f1e22390ac, config space is saved on enumeration, prior to BAR\n> > > correction. Upon passthrough, the corrected BAR is overwritten with the\n> > > incorrect saved value by:\n> > \n> > I'm wondering if there's something that makes this problem specific to \n> > only standard BARs?\n> > \n> > Can other resources, namely IOV resources or bridge windows, similarly be \n> > updated \"too late\" and not get correctly updated into the saved config \n> > space?\n> \n> IOV registers are not saved, they're reconstructed from pci_dev->resource[]:\n> \n> pci_restore_iov_state()\n> sriov_restore_state()\n> pci_update_resource()\n> pci_iov_update_resource()\n>\n> Bridge windows are saved when portdrv probes (see call to pci_save_state()\n> in pcie_portdrv_probe()) and that happens after the fs_initcall() because\n> portdrv is registered from a device_initcall(). So those should be fine\n> as well.\n> \n> (FWIW sashiko also flagged the bridge windows not getting saved as an\n> (alleged) problem.)\n> \n> Thanks for taking a look!\n\nOkay, fair.\n\nIt feels a bit odd they're all handled differently (not a problem when it \ncomes to this patch). Maybe it would make sense to eventually restore them \nall from the pci_dev's resource array. Add something like \npci_restore_resources() that would restore all the resources that are \nrelevant for the type. \n\nI don't know if that's doable when it comes to the order of things, \nespecially with sriov, but if doable, it would prevent them ever getting \nout of sync again and would avoid the trouble of having to save them \nelsewhere.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=b1gDPLPE;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52612-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=\"b1gDPLPE\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=198.175.65.17","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.intel.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxH7M3xJsz1yDF\n\tfor ; Thu, 16 Apr 2026 22:16:47 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 6FDEB3047BC0\n\tfor ; Thu, 16 Apr 2026 12:16:22 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id BBF8539FCD7;\n\tThu, 16 Apr 2026 12:16:21 +0000 (UTC)","from mgamail.intel.com (mgamail.intel.com [198.175.65.17])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 33EC7346FB5\n\tfor ; Thu, 16 Apr 2026 12:16:20 +0000 (UTC)","from fmviesa003.fm.intel.com ([10.60.135.143])\n by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 16 Apr 2026 05:16:20 -0700","from ijarvine-mobl1.ger.corp.intel.com (HELO localhost)\n ([10.245.245.12])\n by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 16 Apr 2026 05:16:11 -0700"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776341781; cv=none;\n b=nyfTmttfZckXJCafHwW+q9X0kpdWG6ADHdnfJjKokSi0d3SI5Dh6OnILDvRjB+p77xeaFJ2A98cOOayttRePrFmr9ZG6UF34SGkbWZ+WAqiWlHgYSeAs+LNOwQ/hChJdQArg1icFpgAyNs8sSepunudik46ZSiD9vAErPGxjTpk=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776341781; c=relaxed/simple;\n\tbh=6yTXq3YM4brCaDe13GHnyt9btEER+c4kciwHNBZ2ISI=;\n\th=From:Date:To:cc:Subject:In-Reply-To:Message-ID:References:\n\t MIME-Version:Content-Type;\n b=mFYq7Iz7Dsrbtsw5IluWT73kfmlIMgo+XpeWDRLFUurS8pX5fBUoYSfq2+Mlupdn9jShf0AEwj8lGJvAgBK5H+1UNNCbfECjTw/BrHn8M/P055YVeCzkYQcjDFJU9RJjC2bFazhe4RscX3MUnNK3V2MT1X3+3VCvIZPFzdf+tkM=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com;\n spf=pass smtp.mailfrom=linux.intel.com;\n dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=b1gDPLPE; arc=none smtp.client-ip=198.175.65.17","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1776341781; x=1807877781;\n h=from:date:to:cc:subject:in-reply-to:message-id:\n references:mime-version;\n bh=6yTXq3YM4brCaDe13GHnyt9btEER+c4kciwHNBZ2ISI=;\n b=b1gDPLPErQaIPfv5zINo6ivyMuZZ0qDisSjyoWS8Jw+VE5bAV7c1XiMD\n UUu/RVCGpaNrbgFcm9QwKMspYUTnuqTaCK7J7+W7W7NXscroAn20PZCcf\n HfXHJ/ehI1KY7fZpAOPNMT0lV/9JFJ4Qb2ABTQkyhHSkaHERBKzK/W1Rk\n dNJJvLrt7/a4yTw7NkoMChxC3M8aAAoC/gP1+fT8rpGatlqqwtyYjZt+d\n WhoHTYTTSrx5oBB/ceDttBBU3+eWQYmIOYgIaD7N/hamJaYsjC7pWvqVk\n lgH8V3gkRq8GOcSI9nJk4A5II8uDtOKLS6L08Cse8/GFVNLqDduqgcTJu\n A==;","X-CSE-ConnectionGUID":["y6sGXenXRSCRxm1Fy6BNJQ==","WuHe+YMFToG6dRRrzTdWFw=="],"X-CSE-MsgGUID":["WP4Sf4MIQNCtZC8+S2O9bA==","Xfz7jsFERumxYO8r/W89tg=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11760\"; a=\"77314091\"","E=Sophos;i=\"6.23,181,1770624000\";\n d=\"scan'208\";a=\"77314091\""],"X-ExtLoop1":"1","From":"=?utf-8?q?Ilpo_J=C3=A4rvinen?= ","Date":"Thu, 16 Apr 2026 15:16:08 +0300 (EEST)","To":"Lukas Wunner ","cc":"Bjorn Helgaas , Bernd Schumacher ,\n \"Alexandre N.\" ,\n Salvatore Bonaccorso , 1131025@bugs.debian.org,\n Uwe Kleine-Koenig ,\n \"Rafael J. Wysocki\" ,\n Mario Limonciello ,\n Alex Williamson , regressions@lists.linux.dev,\n linux-pci@vger.kernel.org","Subject":"Re: [PATCH] PCI: Update saved_config_space upon resource\n assignment","In-Reply-To":"","Message-ID":"<9fcb46ff-56d2-1504-11a1-ad8449c80b2d@linux.intel.com>","References":"\n \n \n ","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"multipart/mixed; boundary=\"8323328-1183682639-1776341768=:1081\""}},{"id":3678146,"web_url":"http://patchwork.ozlabs.org/comment/3678146/","msgid":"","list_archive_url":null,"date":"2026-04-16T12:35:30","subject":"Re: [PATCH] PCI: Update saved_config_space upon resource assignment","submitter":{"id":68499,"url":"http://patchwork.ozlabs.org/api/people/68499/","name":"Lukas Wunner","email":"lukas@wunner.de"},"content":"On Thu, Apr 16, 2026 at 03:16:08PM +0300, Ilpo Järvinen wrote:\n> On Thu, 16 Apr 2026, Lukas Wunner wrote:\n> > IOV registers are not saved, they're reconstructed from\n> > pci_dev->resource[]:\n[...]\n> > Bridge windows are saved when portdrv probes (see call to pci_save_state()\n> > in pcie_portdrv_probe()) and that happens after the fs_initcall() because\n> > portdrv is registered from a device_initcall(). So those should be fine\n> > as well.\n> \n> It feels a bit odd they're all handled differently (not a problem when it \n> comes to this patch). Maybe it would make sense to eventually restore them \n> all from the pci_dev's resource array. Add something like \n> pci_restore_resources() that would restore all the resources that are \n> relevant for the type. \n> \n> I don't know if that's doable when it comes to the order of things, \n> especially with sriov, but if doable, it would prevent them ever getting \n> out of sync again and would avoid the trouble of having to save them \n> elsewhere.\n\nI did consider restoring standard BARs from pci_dev->resource[],\nbut the calculations and iterations involved looked expensive to me,\ncompared to the cheap copying from pci_dev->saved_config_space[]\nthat we currently do. It didn't look like something that lends itself\nwell for a fix that needs to be backported.\n\nA different approach that I'm dwelling on is to amend accessors such as\npci_write_config_dword() to update pci_dev->saved_config_space[]\nimplicitly if the offset in config space is < 64. And also implicitly\nupdate pci_dev->saved_cap_space[]. The former is easy, the latter isn't.\n\nThe end goal would be to remove pci_save_state() everywhere, except to\npopulate the saved state once on enumeration. I think originally the\nidea was, we go to system sleep, so we save state. We resume, we restore\nstate. But then error handling came along and that means we cannot always\nsave the state before reset recovery, so ideally we want to save whenever\nwe write to config space so that cache is never stale.\n\nI'm thinking of having a helper in to determine whether\na register write needs to be saved. Basically, return true for everything\nwith offset < 64 and for Control registers in capabilities, return false\nfor everything else such as Status registers. By having that in a header, \nthe compiler could deduce at compile time whether saving is necessary\nor can be skipped.\n\nThe problem is that to save registers in capabilities, the hlist needs\nto be searched, which is expensive. Maybe we can speed it up by using\nan xarray. Or cache the offset of all capabilities whose registers are\nsaved. We already cache e.g. aer_cap, but other offsets are not cached.\nHmmmm...\n\nThanks,\n\nLukas","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=104.64.211.4; helo=sin.lore.kernel.org;\n envelope-from=linux-pci+bounces-52614-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=83.223.95.204","smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=wunner.de","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=wunner.de"],"Received":["from sin.lore.kernel.org (sin.lore.kernel.org [104.64.211.4])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxHZy74prz1yCv\n\tfor ; Thu, 16 Apr 2026 22:37:14 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 3377B3004695\n\tfor ; Thu, 16 Apr 2026 12:35:38 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 3AD9B39448B;\n\tThu, 16 Apr 2026 12:35:35 +0000 (UTC)","from mailout1.hostsharing.net (mailout1.hostsharing.net\n [83.223.95.204])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 3F27F378D78\n\tfor ; Thu, 16 Apr 2026 12:35:33 +0000 (UTC)","from h08.hostsharing.net (h08.hostsharing.net\n [IPv6:2a01:37:1000::53df:5f1c:0])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384\n\t client-signature ECDSA (secp384r1) client-digest SHA384)\n\t(Client CN \"*.hostsharing.net\",\n Issuer \"GlobalSign GCC R6 AlphaSSL CA 2025\" (verified OK))\n\tby mailout1.hostsharing.net (Postfix) with ESMTPS id E265235C;\n\tThu, 16 Apr 2026 14:35:30 +0200 (CEST)","by h08.hostsharing.net (Postfix, from userid 100393)\n\tid C30C86010C9B; Thu, 16 Apr 2026 14:35:30 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776342935; cv=none;\n b=H8kwiZFkrPgxaI7ryfFZSwy3vHNMP+kJQlcsvd/YQOwKjMOgJYDw2ODybTcCDbip+iqMAR6+Sk2irtPzjHWMWIUCiPSIYwrvGL1TN+ZpEbtDjGQ6BgeTieLUf8NfYM35Idrs8WzsF1VXUIR9wbZwu9KW60wcBGBQT3OL2QIod3U=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776342935; c=relaxed/simple;\n\tbh=heBzkJdeIOXNs6nZLdou7dU2vW2e3qd4H+2Fnrh4KhU=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=hSZaFRqDKDBrR6brsVOJXurm2Jm4eqkj2KQLyfu9IUldf1SQO4dbaQ3QZwcqo5slNSAlgndQkHNFE9zy3nudYz48K0GrBjXmMg7sZPepYs1tNuW1gGDPRAHPX0INDBa+B7KXeYk+hQe4OndZSGqbLpjKADhiguCjUcpRpMP3yZM=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=wunner.de;\n spf=pass smtp.mailfrom=wunner.de; arc=none smtp.client-ip=83.223.95.204","Date":"Thu, 16 Apr 2026 14:35:30 +0200","From":"Lukas Wunner ","To":"Ilpo =?iso-8859-1?q?J=E4rvinen?= ","Cc":"Bjorn Helgaas , Bernd Schumacher ,\n\t\"Alexandre N.\" ,\n\tSalvatore Bonaccorso , 1131025@bugs.debian.org,\n\tUwe Kleine-Koenig ,\n\t\"Rafael J. Wysocki\" ,\n\tMario Limonciello ,\n\tAlex Williamson , regressions@lists.linux.dev,\n\tlinux-pci@vger.kernel.org","Subject":"Re: [PATCH] PCI: Update saved_config_space upon resource assignment","Message-ID":"","References":"\n \n \n \n <9fcb46ff-56d2-1504-11a1-ad8449c80b2d@linux.intel.com>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<9fcb46ff-56d2-1504-11a1-ad8449c80b2d@linux.intel.com>"}},{"id":3683857,"web_url":"http://patchwork.ozlabs.org/comment/3683857/","msgid":"<40051e46-11a8-414a-aa8a-ecb37846a649@leemhuis.info>","list_archive_url":null,"date":"2026-04-29T07:25:42","subject":"Re: [PATCH] PCI: Update saved_config_space upon resource assignment","submitter":{"id":69309,"url":"http://patchwork.ozlabs.org/api/people/69309/","name":"Thorsten Leemhuis","email":"regressions@leemhuis.info"},"content":"Top-posting, to make this easy to process:\n\nBjorn, sorry for bothering you, but I wondered: is below patch still in\nyour review queue? It fixes a regression that made it to a longterm\nseries that two people reported.\n\nCiao, Thorsten\n\nOn 4/15/26 17:56, Lukas Wunner wrote:\n> Bernd reports passthrough failure of a Digital Devices Cine S2 V6 DVB\n> adapter plugged into an ASRock X570S PG Riptide board with BIOS version\n> P5.41 (09/07/2023):\n> \n> ddbridge 0000:05:00.0: detected Digital Devices Cine S2 V6 DVB adapter\n> ddbridge 0000:05:00.0: cannot read registers\n> ddbridge 0000:05:00.0: fail\n> \n> BIOS assigns an incorrect BAR to the DVB adapter which doesn't fit into\n> the upstream bridge window. The kernel corrects the BAR assignment:\n> \n> pci 0000:07:00.0: BAR 0 [mem 0xfffffffffc500000-0xfffffffffc50ffff 64bit]: can't claim; no compatible bridge window\n> pci 0000:07:00.0: BAR 0 [mem 0xfc500000-0xfc50ffff 64bit]: assigned\n> \n> Correction of the BAR assignment happens in an x86-specific fs_initcall,\n> pcibios_assign_resources(), after device enumeration in a subsys_initcall.\n> This order was introduced at the behest of Linus in 2004:\n> \n> https://git.kernel.org/tglx/history/c/a06a30144bbc\n> \n> No other architecture performs such a late BAR correction.\n> \n> Bernd bisected the issue to commit a2f1e22390ac (\"PCI/ERR: Ensure error\n> recoverability at all times\"), but it only occurs in the absence of commit\n> 4d4c10f763d7 (\"PCI: Explicitly put devices into D0 when initializing\").\n> This combination exists in stable kernel v6.12.70, but not in mainline,\n> hence Bernd cannot reproduce the issue with mainline.\n> \n> Since a2f1e22390ac, config space is saved on enumeration, prior to BAR\n> correction. Upon passthrough, the corrected BAR is overwritten with the\n> incorrect saved value by:\n> \n> vfio_pci_core_register_device()\n> vfio_pci_set_power_state()\n> pci_restore_state()\n> \n> But only if the device's current_state is PCI_UNKNOWN, as it was prior to\n> commit 4d4c10f763d7. Since the commit, it is PCI_D0, which changes the\n> behavior of vfio_pci_set_power_state() to no longer restore the state\n> without saving it first.\n> \n> Alexandre is reporting the same issue as Bernd, but in his case, mainline\n> is affected as well. The difference is that on Alexandre's system, the\n> host kernel binds a driver to the device which is unbound prior to\n> passthrough, whereas on Bernd's system no driver gets bound by the host\n> kernel.\n> \n> Unbinding sets current_state to PCI_UNKNOWN in pci_device_remove(), so\n> when vfio-pci is subsequently bound to the device, pci_restore_state() is\n> once again called without invoking pci_save_state() first.\n> \n> To robustly fix the issue, always update saved_config_space upon resource\n> assignment.\n> \n> Reported-by: Bernd Schumacher \n> Tested-by: Bernd Schumacher \n> Closes: https://lore.kernel.org/r/acfZrlP0Ua_5D3U4@eldamar.lan/\n> Reported-by: Alexandre N. \n> Tested-by: Alexandre N. \n> Closes: https://lore.kernel.org/r/dd3c3358-de0f-4a56-9c81-04aceaab4058@mailo.com/\n> Fixes: a2f1e22390ac (\"PCI/ERR: Ensure error recoverability at all times\")\n> Signed-off-by: Lukas Wunner \n> Cc: stable@vger.kernel.org # v6.12+\n> ---\n> drivers/pci/setup-res.c | 2 ++\n> 1 file changed, 2 insertions(+)\n> \n> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c\n> index e5fcadf..1769ba9 100644\n> --- a/drivers/pci/setup-res.c\n> +++ b/drivers/pci/setup-res.c\n> @@ -102,6 +102,7 @@ static void pci_std_update_resource(struct pci_dev *dev, int resno)\n> \t}\n> \n> \tpci_write_config_dword(dev, reg, new);\n> +\tdev->saved_config_space[reg / 4] = new;\n> \tpci_read_config_dword(dev, reg, &check);\n> \n> \tif ((new ^ check) & mask) {\n> @@ -112,6 +113,7 @@ static void pci_std_update_resource(struct pci_dev *dev, int resno)\n> \tif (res->flags & IORESOURCE_MEM_64) {\n> \t\tnew = region.start >> 16 >> 16;\n> \t\tpci_write_config_dword(dev, reg + 4, new);\n> +\t\tdev->saved_config_space[(reg + 4) / 4] = new;\n> \t\tpci_read_config_dword(dev, reg + 4, &check);\n> \t\tif (check != new) {\n> \t\t\tpci_err(dev, \"%s: error updating (high %#010x != %#010x)\\n\",","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=leemhuis.info header.i=@leemhuis.info\n header.a=rsa-sha256 header.s=key2 header.b=kb76pK91;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-53374-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=leemhuis.info header.i=@leemhuis.info\n header.b=\"kb76pK91\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=188.68.63.162","smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=leemhuis.info","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=leemhuis.info","mxe9fb;\n spf=pass (sender IP is 2a02:8108:8984:1d00:a0cf:1912:4be:477f)\n smtp.mailfrom=regressions@leemhuis.info\n smtp.helo=[IPV6:2a02:8108:8984:1d00:a0cf:1912:4be:477f]"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g588n1kQDz1yHv\n\tfor ; Wed, 29 Apr 2026 17:30:17 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id B1C503064CFA\n\tfor ; Wed, 29 Apr 2026 07:26:34 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 7082437BE7A;\n\tWed, 29 Apr 2026 07:26:33 +0000 (UTC)","from relay.yourmailgateway.de (relay.yourmailgateway.de\n [188.68.63.162])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 586A134751D\n\tfor ; Wed, 29 Apr 2026 07:26:31 +0000 (UTC)","from mors-relay-8201.netcup.net (localhost [127.0.0.1])\n\tby mors-relay-8201.netcup.net (Postfix) with ESMTPS id 4g583Z74ptz3y6Z;\n\tWed, 29 Apr 2026 09:25:46 +0200 (CEST)","from policy01-mors.netcup.net (unknown [46.38.225.35])\n\tby mors-relay-8201.netcup.net (Postfix) with ESMTPS id 4g583Z6C2wz3y4w;\n\tWed, 29 Apr 2026 09:25:46 +0200 (CEST)","from mxe9fb.netcup.net (unknown [10.243.12.53])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits)\n server-digest SHA256)\n\t(No client certificate requested)\n\tby policy01-mors.netcup.net (Postfix) with ESMTPS id 4g583W4bVPz8tdJ;\n\tWed, 29 Apr 2026 09:25:43 +0200 (CEST)","from [IPV6:2a02:8108:8984:1d00:a0cf:1912:4be:477f] (unknown\n [IPv6:2a02:8108:8984:1d00:a0cf:1912:4be:477f])\n\tby mxe9fb.netcup.net (Postfix) with ESMTPSA id BEF6A633D0;\n\tWed, 29 Apr 2026 09:25:42 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777447593; cv=none;\n b=TMuh1YqkcAh8N8ckbD25GH6P7slvK6mKQb+DqdTypLGmBB10JcKgqHrt3IFVY2r02IoD0nXirp1YVo121SnOyqhq1bOez2+nnTKuBjUKGY4IGo8VbQc0I6OuzJJnyIhkxBRfV/i5ibted9S8UALpyVJKp9bC8V7QyQREkFarkKE=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777447593; c=relaxed/simple;\n\tbh=oQde5zE4oF8XHfRrVSDCm604TzeXwdKc0Oi7Jedt6/k=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=DGVF+5UloW9hyZajzMPlptt1xE1r0o/7eCQ6N40iTX6NlJqjr5nC5eMkt/MAgTDKBWJhiDyhaD6CElygjRfFdQjFyjsaVXoRL1Suokm2mu2OF2fpav7519qsniGEj/1rzR3exlhvhEBRTWNmHftnZHBmnRZlCMHUC4j5/+dw1EE=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=leemhuis.info;\n spf=pass smtp.mailfrom=leemhuis.info;\n dkim=pass (2048-bit key) header.d=leemhuis.info header.i=@leemhuis.info\n header.b=kb76pK91; arc=none smtp.client-ip=188.68.63.162","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=leemhuis.info;\n\ts=key2; t=1777447547;\n\tbh=oQde5zE4oF8XHfRrVSDCm604TzeXwdKc0Oi7Jedt6/k=;\n\th=Date:Subject:To:Cc:References:From:In-Reply-To:From;\n\tb=kb76pK91Auzn5syjdNDGpF6zxXD3bjETDBPyMsGIAYPemV8k0V4EC1/rpz7iVbDTW\n\t 81IxZFKi266+SmBaa1mIpuOp9NdE1JB86OIrbotLfgyUq6zEtEK6mmZ2qF5+CF+yd8\n\t xcSwkQGOVhZ9uM/3ZnVvjJeYtMvl4jDny5yabRGiVv9qt3L7y77VWqRVzZGXM+FRRi\n\t JMbsaEvrmEiJkMDPXY5OA/pAh4ruKErnnc9rFw9QF57qkhnp9DDuUjA/5rCMdUueTL\n\t 6LpEC+hOn4v2tQeniPSzM/kDNdFi7KN+ok4b4eVewcGRfByaHwCpRu/exRlM5twKwJ\n\t GrE7wxdcrNHXw==","X-Virus-Scanned":"Debian amavisd-new at policy01-mors.netcup.net","X-Spam-Flag":"NO","X-Spam-Score":"-2.898","X-Spam-Level":"","Received-SPF":"pass (mxe9fb: connection is authenticated)","Message-ID":"<40051e46-11a8-414a-aa8a-ecb37846a649@leemhuis.info>","Date":"Wed, 29 Apr 2026 09:25:42 +0200","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] PCI: Update saved_config_space upon resource assignment","To":"Lukas Wunner , Bjorn Helgaas ","Cc":"Bernd Schumacher , \"Alexandre N.\" ,\n Salvatore Bonaccorso , 1131025@bugs.debian.org,\n Uwe Kleine-Koenig ,\n \"Rafael J. Wysocki\" ,\n Mario Limonciello ,\n Alex Williamson ,\n Ilpo Jarvinen , regressions@lists.linux.dev,\n linux-pci@vger.kernel.org","References":"\n ","From":"Thorsten Leemhuis ","Content-Language":"de-DE, en-US","X-Enigmail-Draft-Status":"N11222","Autocrypt":"addr=linux@leemhuis.info; keydata=\n xsFNBFJ4AQ0BEADCz16x4kl/YGBegAsYXJMjFRi3QOr2YMmcNuu1fdsi3XnM+xMRaukWby47\n JcsZYLDKRHTQ/Lalw9L1HI3NRwK+9ayjg31wFdekgsuPbu4x5RGDIfyNpd378Upa8SUmvHik\n apCnzsxPTEE4Z2KUxBIwTvg+snEjgZ03EIQEi5cKmnlaUynNqv3xaGstx5jMCEnR2X54rH8j\n QPvo2l5/79Po58f6DhxV2RrOrOjQIQcPZ6kUqwLi6EQOi92NS9Uy6jbZcrMqPIRqJZ/tTKIR\n OLWsEjNrc3PMcve+NmORiEgLFclN8kHbPl1tLo4M5jN9xmsa0OZv3M0katqW8kC1hzR7mhz+\n Rv4MgnbkPDDO086HjQBlS6Zzo49fQB2JErs5nZ0mwkqlETu6emhxneAMcc67+ZtTeUj54K2y\n Iu8kk6ghaUAfgMqkdIzeSfhO8eURMhvwzSpsqhUs7pIj4u0TPN8OFAvxE/3adoUwMaB+/plk\n sNe9RsHHPV+7LGADZ6OzOWWftk34QLTVTcz02bGyxLNIkhY+vIJpZWX9UrfGdHSiyYThHCIy\n /dLz95b9EG+1tbCIyNynr9TjIOmtLOk7ssB3kL3XQGgmdQ+rJ3zckJUQapLKP2YfBi+8P1iP\n rKkYtbWk0u/FmCbxcBA31KqXQZoR4cd1PJ1PDCe7/DxeoYMVuwARAQABzSdUaG9yc3RlbiBM\n ZWVtaHVpcyA8bGludXhAbGVlbWh1aXMuaW5mbz7CwZQEEwEKAD4CGwMFCwkIBwMFFQoJCAsF\n FgIDAQACHgECF4AWIQSoq8a+lZZX4oPULXVytubvTFg9LQUCaOO74gUJHfEI0wAKCRBytubv\n TFg9Lc4iD/4omf2z88yGmior2f1BCQTAWxI2Em3S4EJY2+Drs8ZrJ1vNvdWgBrqbOtxN6xHF\n uvrpM6nbYIoNyZpsZrqS1mCA4L7FwceFBaT9CTlQsZLVV/vQvh2/3vbj6pQbCSi7iemXklF7\n y6qMfA7rirvojSJZ2mi6tKIQnD2ndVhSsxmo/mAAJc4tiEL+wkdaX1p7bh2Ainp6sfxTqL6h\n z1kYyjnijpnHaPgQ6GQeGG1y+TSQFKkb/FylDLj3b3efzyNkRjSohcauTuYIq7bniw7sI8qY\n KUuUkrw8Ogi4e6GfBDgsgHDngDn6jUR2wDAiT6iR7qsoxA+SrJDoeiWS/SK5KRgiKMt66rx1\n Jq6JowukzNxT3wtXKuChKP3EDzH9aD+U539szyKjfn5LyfHBmSfR42Iz0sofE4O89yvp0bYz\n GDmlgDpYWZN40IFERfCSxqhtHG1X6mQgxS0MknwoGkNRV43L3TTvuiNrsy6Mto7rrQh0epSn\n +hxwwS0bOTgJQgOO4fkTvto2sEBYXahWvmsEFdLMOcAj2t7gJ+XQLMsBypbo94yFYfCqCemJ\n +zU5X8yDUeYDNXdR2veePdS3Baz23/YEBCOtw+A9CP0U4ImXzp82U+SiwYEEQIGWx+aVjf4n\n RZ/LLSospzO944PPK+Na+30BERaEjx04MEB9ByDFdfkSbM7BTQRSeAENARAAzu/3satWzly6\n +Lqi5dTFS9+hKvFMtdRb/vW4o9CQsMqL2BJGoE4uXvy3cancvcyodzTXCUxbesNP779JqeHy\n s7WkF2mtLVX2lnyXSUBm/ONwasuK7KLz8qusseUssvjJPDdw8mRLAWvjcsYsZ0qgIU6kBbvY\n ckUWkbJj/0kuQCmmulRMcaQRrRYrk7ZdUOjaYmjKR+UJHljxLgeregyiXulRJxCphP5migoy\n ioa1eset8iF9fhb+YWY16X1I3TnucVCiXixzxwn3uwiVGg28n+vdfZ5lackCOj6iK4+lfzld\n z4NfIXK+8/R1wD9yOj1rr3OsjDqOaugoMxgEFOiwhQDiJlRKVaDbfmC1G5N1YfQIn90znEYc\n M7+Sp8Rc5RUgN5yfuwyicifIJQCtiWgjF8ttcIEuKg0TmGb6HQHAtGaBXKyXGQulD1CmBHIW\n zg7bGge5R66hdbq1BiMX5Qdk/o3Sr2OLCrxWhqMdreJFLzboEc0S13BCxVglnPqdv5sd7veb\n 0az5LGS6zyVTdTbuPUu4C1ZbstPbuCBwSwe3ERpvpmdIzHtIK4G9iGIR3Seo0oWOzQvkFn8m\n 2k6H2/Delz9IcHEefSe5u0GjIA18bZEt7R2k8CMZ84vpyWOchgwXK2DNXAOzq4zwV8W4TiYi\n FiIVXfSj185vCpuE7j0ugp0AEQEAAcLBfAQYAQoAJgIbDBYhBKirxr6Vllfig9QtdXK25u9M\n WD0tBQJo47viBQkd8QjTAAoJEHK25u9MWD0tCH8P/1b+AZ8K3D4TCBzXNS0muN6pLnISzFa0\n cWcylwxX2TrZeGpJkg14v2R0cDjLRre9toM44izLaz4SKyfgcBSj9XET0103cVXUKt6SgT1o\n tevoEqFMKKp3vjDpKEnrcOSOCnfH9W0mXx/jDWbjlKbBlN7UBVoZD/FMM5Ul0KSVFJ9Uij0Z\n S2WAg50NQi71NBDPcga21BMajHKLFzb4wlBWSmWyryXI6ouabvsbsLjkW3IYl2JupTbK3viH\n pMRIZVb/serLqhJgpaakqgV7/jDplNEr/fxkmhjBU7AlUYXe2BRkUCL5B8KeuGGvG0AEIQR0\n dP6QlNNBV7VmJnbU8V2X50ZNozdcvIB4J4ncK4OznKMpfbmSKm3t9Ui/cdEK+N096ch6dCAh\n AeZ9dnTC7ncr7vFHaGqvRC5xwpbJLg3xM/BvLUV6nNAejZeAXcTJtOM9XobCz/GeeT9prYhw\n 8zG721N4hWyyLALtGUKIVWZvBVKQIGQRPtNC7s9NVeLIMqoH7qeDfkf10XL9tvSSDY6KVl1n\n K0gzPCKcBaJ2pA1xd4pQTjf4jAHHM4diztaXqnh4OFsu3HOTAJh1ZtLvYVj5y9GFCq2azqTD\n pPI3FGMkRipwxdKGAO7tJVzM7u+/+83RyUjgAbkkkD1doWIl+iGZ4s/Jxejw1yRH0R5/uTaB MEK4","In-Reply-To":"\n ","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","X-PPP-Message-ID":"<177744754331.2437893.7300139824891796474@mxe9fb.netcup.net>","X-NC-CID":"4H1AzZDm7MNaS380OBd68xyjr7zkXvMklCezlslU6cqGG3sGses="}},{"id":3685216,"web_url":"http://patchwork.ozlabs.org/comment/3685216/","msgid":"<20260501195118.GA516950@bhelgaas>","list_archive_url":null,"date":"2026-05-01T19:51:18","subject":"Re: [PATCH] PCI: Update saved_config_space upon resource assignment","submitter":{"id":67298,"url":"http://patchwork.ozlabs.org/api/people/67298/","name":"Bjorn Helgaas","email":"helgaas@kernel.org"},"content":"[+cc Thorsten, thanks for the reminder!]\n\nOn Wed, Apr 15, 2026 at 05:56:06PM +0200, Lukas Wunner wrote:\n> Bernd reports passthrough failure of a Digital Devices Cine S2 V6 DVB\n> adapter plugged into an ASRock X570S PG Riptide board with BIOS version\n> P5.41 (09/07/2023):\n> \n> ddbridge 0000:05:00.0: detected Digital Devices Cine S2 V6 DVB adapter\n> ddbridge 0000:05:00.0: cannot read registers\n> ddbridge 0000:05:00.0: fail\n> \n> BIOS assigns an incorrect BAR to the DVB adapter which doesn't fit into\n> the upstream bridge window. The kernel corrects the BAR assignment:\n> \n> pci 0000:07:00.0: BAR 0 [mem 0xfffffffffc500000-0xfffffffffc50ffff 64bit]: can't claim; no compatible bridge window\n> pci 0000:07:00.0: BAR 0 [mem 0xfc500000-0xfc50ffff 64bit]: assigned\n> \n> Correction of the BAR assignment happens in an x86-specific fs_initcall,\n> pcibios_assign_resources(), after device enumeration in a subsys_initcall.\n> This order was introduced at the behest of Linus in 2004:\n> \n> https://git.kernel.org/tglx/history/c/a06a30144bbc\n> \n> No other architecture performs such a late BAR correction.\n> \n> Bernd bisected the issue to commit a2f1e22390ac (\"PCI/ERR: Ensure error\n> recoverability at all times\"), but it only occurs in the absence of commit\n> 4d4c10f763d7 (\"PCI: Explicitly put devices into D0 when initializing\").\n> This combination exists in stable kernel v6.12.70, but not in mainline,\n> hence Bernd cannot reproduce the issue with mainline.\n> \n> Since a2f1e22390ac, config space is saved on enumeration, prior to BAR\n> correction. Upon passthrough, the corrected BAR is overwritten with the\n> incorrect saved value by:\n> \n> vfio_pci_core_register_device()\n> vfio_pci_set_power_state()\n> pci_restore_state()\n> \n> But only if the device's current_state is PCI_UNKNOWN, as it was prior to\n> commit 4d4c10f763d7. Since the commit, it is PCI_D0, which changes the\n> behavior of vfio_pci_set_power_state() to no longer restore the state\n> without saving it first.\n> \n> Alexandre is reporting the same issue as Bernd, but in his case, mainline\n> is affected as well. The difference is that on Alexandre's system, the\n> host kernel binds a driver to the device which is unbound prior to\n> passthrough, whereas on Bernd's system no driver gets bound by the host\n> kernel.\n> \n> Unbinding sets current_state to PCI_UNKNOWN in pci_device_remove(), so\n> when vfio-pci is subsequently bound to the device, pci_restore_state() is\n> once again called without invoking pci_save_state() first.\n> \n> To robustly fix the issue, always update saved_config_space upon resource\n> assignment.\n> \n> Reported-by: Bernd Schumacher \n> Tested-by: Bernd Schumacher \n> Closes: https://lore.kernel.org/r/acfZrlP0Ua_5D3U4@eldamar.lan/\n> Reported-by: Alexandre N. \n> Tested-by: Alexandre N. \n> Closes: https://lore.kernel.org/r/dd3c3358-de0f-4a56-9c81-04aceaab4058@mailo.com/\n> Fixes: a2f1e22390ac (\"PCI/ERR: Ensure error recoverability at all times\")\n> Signed-off-by: Lukas Wunner \n> Cc: stable@vger.kernel.org # v6.12+\n\na2f1e22390ac appeared in v6.19. Applied this fix to pci/for-linus for\nv7.1, thanks!\n\n> ---\n> drivers/pci/setup-res.c | 2 ++\n> 1 file changed, 2 insertions(+)\n> \n> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c\n> index e5fcadf..1769ba9 100644\n> --- a/drivers/pci/setup-res.c\n> +++ b/drivers/pci/setup-res.c\n> @@ -102,6 +102,7 @@ static void pci_std_update_resource(struct pci_dev *dev, int resno)\n> \t}\n> \n> \tpci_write_config_dword(dev, reg, new);\n> +\tdev->saved_config_space[reg / 4] = new;\n> \tpci_read_config_dword(dev, reg, &check);\n> \n> \tif ((new ^ check) & mask) {\n> @@ -112,6 +113,7 @@ static void pci_std_update_resource(struct pci_dev *dev, int resno)\n> \tif (res->flags & IORESOURCE_MEM_64) {\n> \t\tnew = region.start >> 16 >> 16;\n> \t\tpci_write_config_dword(dev, reg + 4, new);\n> +\t\tdev->saved_config_space[(reg + 4) / 4] = new;\n> \t\tpci_read_config_dword(dev, reg + 4, &check);\n> \t\tif (check != new) {\n> \t\t\tpci_err(dev, \"%s: error updating (high %#010x != %#010x)\\n\",\n> -- \n> 2.51.0\n>","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=srPRTdlj;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-53605-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"srPRTdlj\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g6hW15DHbz1xvV\n\tfor ; Sat, 02 May 2026 05:51:25 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 3CEDF300C9A9\n\tfor ; Fri, 1 May 2026 19:51:22 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 8030E3D16EC;\n\tFri, 1 May 2026 19:51:20 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 5DE553CFF56;\n\tFri, 1 May 2026 19:51:20 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id BCFE5C2BCB4;\n\tFri, 1 May 2026 19:51:19 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777665080; cv=none;\n b=RriGK0GPxEm0O5YX8RoPvFbepLJUttQTIEbGiQD/hreb7V+5THBQFJ4pO8TLszB97TR0EyFkK68oi+Ft1GXlBZegspvAPW6zFqpkBwaEDDgy76+d3brHXfvOmdFeQ14oGn+vsgAfpLB1kZl/Q2ADGe+U3okV8e5V7kSpQUqzwqE=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777665080; c=relaxed/simple;\n\tbh=2lwK0DRmBaAJw8gyAufqK7jzcxgKzRLJfNjgaScql5g=;\n\th=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type:\n\t Content-Disposition:In-Reply-To;\n b=FxEHmZwszKnULk0rdV+gHUto61rJgp2S9/LoCk2CqNIrpJ2u8RFkp6QXZqWGs63+/eMrQhP0oMlTA+9hp/edblDMdNVpqLSlnDH2rq0Mc8SEXtFWZPX7ucuN8uPwVeflUM3ZNIycyw+vJILxZsnlEd2qiU3D4LXe36jxOQMaOGU=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=srPRTdlj; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1777665080;\n\tbh=2lwK0DRmBaAJw8gyAufqK7jzcxgKzRLJfNjgaScql5g=;\n\th=Date:From:To:Cc:Subject:In-Reply-To:From;\n\tb=srPRTdljPgAgcQl0cQ2FP8JuQz/ZBexicobfWo69YwU+2UWBwJMaKBJ4KUkKv4hfB\n\t Ggbk8HPpnvZOsVBaVEiWVbxIhmXt1JLyT93k4gNmVYoo1eBEQi3yeV0gS7GcqmU7Vm\n\t l4rVDMXhBsHJtaJZP+sUSPv2N/ExfiAXZBUgh+PlzPK75cgSk1Ncb+gYZ1LeClu3cN\n\t nWCkrtANJoUVQUZuYpbi5U6IwrUqH+P+Ie6N17lbtb58tbKFVUtb+/8E53qJ6IXnew\n\t W+/S35PeavybIrWSDXd2qpFnpldRFg2y9VlHnsii0z7hD/8tQXRUTi7TqQYqYXTGOm\n\t Ie9n7fy5r058A==","Date":"Fri, 1 May 2026 14:51:18 -0500","From":"Bjorn Helgaas ","To":"Lukas Wunner ","Cc":"Bernd Schumacher , \"Alexandre N.\" ,\n\tSalvatore Bonaccorso , 1131025@bugs.debian.org,\n\tUwe Kleine-Koenig ,\n\t\"Rafael J. Wysocki\" ,\n\tMario Limonciello ,\n\tAlex Williamson ,\n\tIlpo Jarvinen ,\n\tregressions@lists.linux.dev, linux-pci@vger.kernel.org,\n\tThorsten Leemhuis ","Subject":"Re: [PATCH] PCI: Update saved_config_space upon resource assignment","Message-ID":"<20260501195118.GA516950@bhelgaas>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"\n "}}]