public inbox for linux-pci@vger.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	Bernd Schumacher <bernd@bschu.de>,
	"Alexandre N." <an.tech@mailo.com>,
	Salvatore Bonaccorso <carnil@debian.org>,
	1131025@bugs.debian.org, Uwe Kleine-Koenig <ukleinek@debian.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Mario Limonciello <mario.limonciello@amd.com>,
	Alex Williamson <alex@shazbot.org>,
	regressions@lists.linux.dev, linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI: Update saved_config_space upon resource assignment
Date: Thu, 16 Apr 2026 14:35:30 +0200	[thread overview]
Message-ID: <aeDXktnNLEtmYsbh@wunner.de> (raw)
In-Reply-To: <9fcb46ff-56d2-1504-11a1-ad8449c80b2d@linux.intel.com>

On Thu, Apr 16, 2026 at 03:16:08PM +0300, Ilpo Järvinen wrote:
> On Thu, 16 Apr 2026, Lukas Wunner wrote:
> > IOV registers are not saved, they're reconstructed from
> > pci_dev->resource[]:
[...]
> > Bridge windows are saved when portdrv probes (see call to pci_save_state()
> > in pcie_portdrv_probe()) and that happens after the fs_initcall() because
> > portdrv is registered from a device_initcall().  So those should be fine
> > as well.
> 
> It feels a bit odd they're all handled differently (not a problem when it 
> comes to this patch). Maybe it would make sense to eventually restore them 
> all from the pci_dev's resource array. Add something like 
> pci_restore_resources() that would restore all the resources that are 
> relevant for the type. 
> 
> I don't know if that's doable when it comes to the order of things, 
> especially with sriov, but if doable, it would prevent them ever getting 
> out of sync again and would avoid the trouble of having to save them 
> elsewhere.

I did consider restoring standard BARs from pci_dev->resource[],
but the calculations and iterations involved looked expensive to me,
compared to the cheap copying from pci_dev->saved_config_space[]
that we currently do.  It didn't look like something that lends itself
well for a fix that needs to be backported.

A different approach that I'm dwelling on is to amend accessors such as
pci_write_config_dword() to update pci_dev->saved_config_space[]
implicitly if the offset in config space is < 64.  And also implicitly
update pci_dev->saved_cap_space[].  The former is easy, the latter isn't.

The end goal would be to remove pci_save_state() everywhere, except to
populate the saved state once on enumeration.  I think originally the
idea was, we go to system sleep, so we save state.  We resume, we restore
state.  But then error handling came along and that means we cannot always
save the state before reset recovery, so ideally we want to save whenever
we write to config space so that cache is never stale.

I'm thinking of having a helper in <linux/pci.h> to determine whether
a register write needs to be saved.  Basically, return true for everything
with offset < 64 and for Control registers in capabilities, return false
for everything else such as Status registers.  By having that in a header, 
the compiler could deduce at compile time whether saving is necessary
or can be skipped.

The problem is that to save registers in capabilities, the hlist needs
to be searched, which is expensive.  Maybe we can speed it up by using
an xarray.  Or cache the offset of all capabilities whose registers are
saved.  We already cache e.g. aer_cap, but other offsets are not cached.
Hmmmm...

Thanks,

Lukas

      reply	other threads:[~2026-04-16 12:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-15 15:56 [PATCH] PCI: Update saved_config_space upon resource assignment Lukas Wunner
2026-04-16 11:08 ` Ilpo Järvinen
2026-04-16 11:28   ` Lukas Wunner
2026-04-16 12:16     ` Ilpo Järvinen
2026-04-16 12:35       ` Lukas Wunner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aeDXktnNLEtmYsbh@wunner.de \
    --to=lukas@wunner.de \
    --cc=1131025@bugs.debian.org \
    --cc=alex@shazbot.org \
    --cc=an.tech@mailo.com \
    --cc=bernd@bschu.de \
    --cc=carnil@debian.org \
    --cc=helgaas@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=rafael@kernel.org \
    --cc=regressions@lists.linux.dev \
    --cc=ukleinek@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox