From: Farhan Ali <alifm@linux.ibm.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, lukas@wunner.de, alex@shazbot.org,
clg@redhat.com, kbusch@kernel.org, schnelle@linux.ibm.com,
mjrosato@linux.ibm.com, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v12 2/7] PCI: Avoid saving config space state if inaccessible
Date: Tue, 7 Apr 2026 15:02:35 -0700 [thread overview]
Message-ID: <56029c2e-6814-4c3a-b14a-fac7e6da31da@linux.ibm.com> (raw)
In-Reply-To: <20260407213207.GA257253@bhelgaas>
On 4/7/2026 2:32 PM, Bjorn Helgaas wrote:
> On Tue, Apr 07, 2026 at 02:17:07PM -0700, Farhan Ali wrote:
>> On 4/7/2026 12:56 PM, Bjorn Helgaas wrote:
>>> On Mon, Mar 30, 2026 at 10:40:06AM -0700, Farhan Ali wrote:
>>>> The current reset process saves the device's config space state before
>>>> reset and restores it afterward. However errors may occur unexpectedly and
>>>> it may then be impossible to save config space because the device may be
>>>> inaccessible (e.g. DPC). This results in saving invalid values that get
>>>> written back to the device during state restoration.
>>>>
>>>> With a reset we want to recover/restore the device into a functional state.
>>>> So avoid saving the state of the config space when the device config space
>>>> is inaccessible.
>>>>
>>>> Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
>>>> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
>>>> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
>>>> ---
>>>> drivers/pci/pci.c | 24 ++++++++++++++++++++++++
>>>> 1 file changed, 24 insertions(+)
>>>>
>>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>>> index 70162f15a72c..b36263834289 100644
>>>> --- a/drivers/pci/pci.c
>>>> +++ b/drivers/pci/pci.c
>>>> @@ -722,6 +722,27 @@ u16 pci_find_dvsec_capability(struct pci_dev *dev, u16 vendor, u16 dvsec)
>>>> }
>>>> EXPORT_SYMBOL_GPL(pci_find_dvsec_capability);
>>>> +static bool pci_dev_config_accessible(struct pci_dev *dev, char *msg)
>>>> +{
>>>> + u32 val;
>>>> +
>>>> + /*
>>>> + * If device's config space is inaccessible it can return ~0 for
>>>> + * any reads. Since VFs can also return ~0 for Device and Vendor ID
>>>> + * check Command and Status registers. Note that this is racy
>>>> + * because the device may become inaccessible partway through
>>>> + * next access.
>>>> + */
>>>> + pci_read_config_dword(dev, PCI_COMMAND, &val);
>>>> + if (PCI_POSSIBLE_ERROR(val)) {
>>>> + pci_warn(dev, "Device config space inaccessible; unable to %s\n",
>>>> + msg);
>>>> + return false;
>>> I wonder if it's feasible to do the pci_save_state() into a temporary
>>> buffer, check the buffer for PCI_POSSIBLE_ERROR(), and copy the temp
>>> buffer into the real buffer if we think the save was successful. I
>>> know this is a lot more work, but I would like to avoid the raciness
>>> if possible.
>> I just want to clarify, are you suggesting we do that in pci_save_state()
>> function? If not then we need to do something similar to pci_save_state()
>> and then check for errors. At that point wouldn't it just make sense to add
>> the check in places where we save the bits the kernel wants? Please correct
>> me if I misunderstood you.
> This is kind of a blue-sky idea for exploration, so maybe it's not
> practical. I think it have to be done inside pci_save_state(). It
> would be a little messy to implement since the pci_cap_saved_state
> structures are in the save_cap_space list, not all in one place. So I
> think we'd have to allocate a duplicate list for this purpose.
Yeah this would require quite a bit of work and would need some
refactoring on how we save state today. I would prefer to avoid doing
that as part of this series. I also think doing this for checking FLR
(the following patch in this series) would be an overkill?
Just trying to think out loud (and exploring the idea further), I wonder
how expensive it would be then to save the state as we would need to
check all the bits the kernel cares about?
Thanks
Farhan
next prev parent reply other threads:[~2026-04-07 22:02 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 17:40 [PATCH v12 0/7] Error recovery for vfio-pci devices on s390x Farhan Ali
2026-03-30 17:40 ` [PATCH v12 1/7] PCI: Allow per function PCI slots to fix slot reset on s390 Farhan Ali
2026-03-30 17:40 ` [PATCH v12 2/7] PCI: Avoid saving config space state if inaccessible Farhan Ali
2026-04-07 19:56 ` Bjorn Helgaas
2026-04-07 21:17 ` Farhan Ali
2026-04-07 21:32 ` Bjorn Helgaas
2026-04-07 22:02 ` Farhan Ali [this message]
2026-03-30 17:40 ` [PATCH v12 3/7] PCI: Fail FLR when config space is inaccessible Farhan Ali
2026-03-30 17:40 ` [PATCH v12 4/7] s390/pci: Store PCI error information for passthrough devices Farhan Ali
2026-03-31 17:41 ` Matthew Rosato
2026-03-31 19:23 ` Farhan Ali
2026-03-31 19:29 ` Matthew Rosato
2026-04-07 15:38 ` Alex Williamson
2026-04-07 18:00 ` Farhan Ali
2026-04-07 18:23 ` Alex Williamson
2026-03-30 17:40 ` [PATCH v12 5/7] vfio-pci/zdev: Add a device feature for error information Farhan Ali
2026-03-31 17:42 ` Matthew Rosato
2026-03-31 19:27 ` Farhan Ali
2026-04-07 15:53 ` Alex Williamson
2026-04-07 18:13 ` Farhan Ali
2026-04-07 18:27 ` Alex Williamson
2026-03-30 17:40 ` [PATCH v12 6/7] vfio/pci: Add a reset_done callback for vfio-pci driver Farhan Ali
2026-03-31 17:43 ` Matthew Rosato
2026-03-30 17:40 ` [PATCH v12 7/7] vfio/pci: Remove the pcie check for VFIO_PCI_ERR_IRQ_INDEX Farhan Ali
2026-04-07 15:58 ` Alex Williamson
2026-04-06 17:23 ` [PATCH v12 0/7] Error recovery for vfio-pci devices on s390x Farhan Ali
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=56029c2e-6814-4c3a-b14a-fac7e6da31da@linux.ibm.com \
--to=alifm@linux.ibm.com \
--cc=alex@shazbot.org \
--cc=bhelgaas@google.com \
--cc=clg@redhat.com \
--cc=helgaas@kernel.org \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mjrosato@linux.ibm.com \
--cc=schnelle@linux.ibm.com \
/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