From: Bjorn Helgaas <helgaas@kernel.org>
To: "Kuppuswamy,
Sathyanarayanan" <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Austin.Bolen@dell.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, ashok.raj@intel.com,
Russell Currey <ruscur@russell.cc>,
Sam Bobroff <sbobroff@linux.ibm.com>,
Oliver O'Halloran <oohall@gmail.com>
Subject: Re: [PATCH v17 09/12] PCI/AER: Allow clearing Error Status Register in FF mode
Date: Fri, 13 Mar 2020 14:28:16 -0500 [thread overview]
Message-ID: <20200313192816.GA127896@google.com> (raw)
In-Reply-To: <4d06c72d-7f77-84d5-4163-187bc62b903a@linux.intel.com>
[+cc Russell, Sam, Oliver since we're talking about the error recovery
flow. The code we're talking about is at [1]]
On Thu, Mar 12, 2020 at 11:22:13PM -0700, Kuppuswamy, Sathyanarayanan wrote:
> On 3/12/2020 3:32 PM, Bjorn Helgaas wrote:
> > On Thu, Mar 12, 2020 at 02:59:15PM -0700, Kuppuswamy Sathyanarayanan wrote:
> > > On 3/12/20 12:53 PM, Bjorn Helgaas wrote:
> > > > On Wed, Mar 11, 2020 at 04:07:59PM -0700, Kuppuswamy Sathyanarayanan wrote:
> > > > > On 3/11/20 3:23 PM, Bjorn Helgaas wrote:
> > > > > > Is any synchronization needed here between the EDR path and the
> > > > > > hotplug/enumeration path?
> > > > > If we want to follow the implementation note step by step (in
> > > > > sequence) then we need some synchronization between EDR path and
> > > > > enumeration path. But if it's OK to achieve the same end result by
> > > > > following steps out of sequence then we don't need to create any
> > > > > dependency between EDR and enumeration paths. Currently we follow
> > > > > the latter approach.
> > > > What would the synchronization look like?
> > > we might need some way to disable the enumeration path till
> > > we get response from firmware.
> > >
> > > In native hot plug case, I think we can do it in two ways.
> > >
> > > 1. Disable hotplug notification in slot ctl registers.
> > > (pcie_disable_notification())
> > > 2. Some how block hotplug driver from processing the new
> > > events (not sure how feasible its).
> > >
> > > Following method 1 would be easy, But I am not sure whether
> > > its alright to disable them randomly. I think, unless we
> > > clear the status as well, we might get some issues due to stale
> > > notification history.
> > >
> > > For ACPI event case, I am not sure whether we have some
> > > communication protocol in place to disable receiving ACPI
> > > events temporarily.
> > >
> > > For polling model, we need to disable to the polling
> > > timer thread till we receive _OST response from firmware.
> > > >
> > > > Ideally I think it would be better to follow the order in the
> > > > flowchart if it's not too onerous.
> > > None of the above changes will be pretty and I think it will
> > > not be simple as well.
> > > > That will make the code easier to
> > > > understand. The current situation with this dependency on pciehp and
> > > > what it will do leaves a lot of things implicit.
> > > >
> > > > What happens if CONFIG_PCIE_EDR=y but CONFIG_HOTPLUG_PCI_PCIE=n?
> > > >
> > > > IIUC, when DPC triggers, pciehp is what fields the DLLSC interrupt and
> > > > unbinds the drivers and removes the devices.
> > >
> > > > If that doesn't happen, and Linux clears the DPC trigger to bring
> > > > the link back up, will those drivers try to operate uninitialized
> > > > devices?
> > >
> > > I don't think this will happen. In DPC reset_link before we bring up
> > > the device we wait for link to go down first using
> > > pcie_wait_for_link(pdev, false) function.
> >
> > I understand that, but these child devices were reset when DPC
> > disabled the link. When the link comes back up, their BARs
> > contain zeros.
> >
> > If CONFIG_HOTPLUG_PCI_PCIE=y, the DLLSC interrupt will cause
> > pciehp to unbind the driver. It seems like the unbind races with
> > the EDR notify handler.
>
> Agree. But even if there is a race condition, after clearing DPC
> trigger status, if hotplug driver properly removes/re-enumerates the
> driver then the end result will still be same. There should be no
> functional impact.
>
> > If pciehp unbinds the driver before edr_handle_event() calls
> > pcie_do_recovery(), this seems fine -- we'll call
> > dpc_reset_link(), which brings up the link, we won't call any
> > driver callbacks because there's no driver, and another DLLSC
> > interrupt will cause pciehp to re-enumerate, which will
> > re-initialize the device, then rebind the driver.
> >
> > If the EDR notify handler runs before pciehp unbinds the driver,
>
> In the above case, from the kernel perspective device is still
> accessible and IIUC, it will try to recover it in pcie_do_recovery()
> using one of the callbacks.
>
> int (*mmio_enabled)(struct pci_dev *dev);
> int (*slot_reset)(struct pci_dev *dev);
> void (*resume)(struct pci_dev *dev);
>
> One of these callbacks will do pci_restore_state() to restore the
> device, and IO will not attempted in these callbacks until the device
> is successfully recovered.
That might be what *should* happen, but I don't think it's what
*does* happen.
I don't think we use .mmio_enabled() and .slot_reset() for EDR
because Linux EDR currently depends on DPC, so we'll be using
dpc_reset_link(), which normally returns PCI_ERS_RESULT_RECOVERED,
so pcie_do_recovery() skips .mmio_enabled() and .slot_reset().
I looked at the first few .resume() implementations (FWIW, I used [2]
to find them), and none of them calls pci_restore_state() before doing
I/O to the device:
ioat_pcie_error_resume()
pci_resume() (hfi1)
qib_pci_resume()
cxl_pci_resume()
genwqe_err_resume()
...
But I assume you've tested EDR with some driver that *does* call
pci_restore_state()? Or maybe you have pciehp enabled, and it always
wins the race and unbinds the driver before the EDR notification? It
would be interesting to make pciehp *lose* the race and see if
anything breaks.
pci-error-recovery.rst does not mention any requirement for the driver
to call pci_restore_state(), and I think any state restoration like
that should be the responsibility of the PCI core, not the driver.
> > couldn't EDR bring up the link and call driver .mmio_enabled() before
> > the device has been initialized?
>
> Calling mmio_enabled in this case should not be a problem right?
>
> Please check the following content from
> Documentation/PCI/pci-error-recovery.rst. IIUC (following content),
> IO will not be attempted until the device is successfully
> re-configured.
>
> STEP 2: MMIO Enabled
> --------------------
> This callback is made if all drivers on a segment agree that they can
> try to recover and if no automatic link reset was performed by the HW.
> If the platform can't just re-enable IOs without a slot reset or a link
> reset, it will not call this callback, and instead will have gone
> directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset)
>
> > If CONFIG_HOTPLUG_PCI_PCIE=n and CONFIG_HOTPLUG_PCI_ACPI=y, I could
> > believe that the situations are similar to the above.
> >
> > What if CONFIG_HOTPLUG_PCI_PCIE=n and CONFIG_HOTPLUG_PCI_ACPI=n? Then
> > I assume there's nothing to unbind the driver, so pcie_do_recovery()
> > will call the driver .mmio_enabled() and other recovery callbacks on a
> > device that hasn't been initialized?
>
> probably in .slot_reset() callback device config will be restored and it
> will make the device functional again.
I don't think .mmio_enabled() is a problem because IIUC, the device
should not have been reset before calling .mmio_enabled().
But I think .slot_reset() *is* a problem. I looked at several
.slot_reset() implementations ([3]); some called pci_restore_state(),
but many did not.
If no hotplug driver is enabled, I think the .slot_reset() callbacks
that do not call pci_restore_state() are broken.
> Also since in above case hotplug is not supported, topology change will
> not be supported.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/log/?h=review/edr
[2] F='\.resume'; git grep -A 10 "struct pci_error_handlers" | grep "$F\s*=" | sed -e "s/.*$F\s*=\s*//" -e 's/,\s*$//'
[3] F='\.slot_reset'; git grep -A 10 "struct pci_error_handlers" | grep "$F\s*=" | sed -e "s/.*$F\s*=\s*//" -e 's/,\s*$//'
next prev parent reply other threads:[~2020-03-13 19:28 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-04 2:36 [PATCH v17 00/12] Add Error Disconnect Recover (EDR) support sathyanarayanan.kuppuswamy
2020-03-04 2:36 ` [PATCH v17 01/12] PCI/ERR: Update error status after reset_link() sathyanarayanan.kuppuswamy
2020-03-04 2:36 ` [PATCH v17 02/12] PCI/AER: Move pci_cleanup_aer_error_status_regs() declaration to pci.h sathyanarayanan.kuppuswamy
2020-03-04 2:36 ` [PATCH v17 03/12] PCI/ERR: Remove service dependency in pcie_do_recovery() sathyanarayanan.kuppuswamy
2020-03-17 14:40 ` Christoph Hellwig
2020-03-04 2:36 ` [PATCH v17 04/12] PCI: portdrv: remove unnecessary pcie_port_find_service() sathyanarayanan.kuppuswamy
2020-03-04 2:36 ` [PATCH v17 05/12] PCI: portdrv: remove reset_link member from pcie_port_service_driver sathyanarayanan.kuppuswamy
2020-03-17 14:41 ` Christoph Hellwig
2020-03-17 14:55 ` Kuppuswamy, Sathyanarayanan
2020-03-04 2:36 ` [PATCH v17 06/12] Documentation: PCI: Remove reset_link references sathyanarayanan.kuppuswamy
2020-03-17 14:42 ` Christoph Hellwig
2020-03-17 15:05 ` Kuppuswamy, Sathyanarayanan
2020-03-17 15:07 ` Christoph Hellwig
2020-03-17 16:03 ` Bjorn Helgaas
2020-03-17 17:06 ` Christoph Hellwig
2020-03-19 22:52 ` Bjorn Helgaas
2020-03-04 2:36 ` [PATCH v17 07/12] PCI/ERR: Return status of pcie_do_recovery() sathyanarayanan.kuppuswamy
2020-03-04 2:36 ` [PATCH v17 08/12] PCI/DPC: Cache DPC capabilities in pci_init_capabilities() sathyanarayanan.kuppuswamy
2020-03-04 2:36 ` [PATCH v17 09/12] PCI/AER: Allow clearing Error Status Register in FF mode sathyanarayanan.kuppuswamy
2020-03-06 5:45 ` Kuppuswamy, Sathyanarayanan
2020-03-06 16:04 ` Bjorn Helgaas
2020-03-06 16:11 ` Kuppuswamy, Sathyanarayanan
2020-03-06 16:41 ` Bjorn Helgaas
2020-03-10 2:40 ` Bjorn Helgaas
2020-03-10 4:28 ` Kuppuswamy, Sathyanarayanan
2020-03-10 18:14 ` Austin.Bolen
2020-03-10 19:32 ` Bjorn Helgaas
2020-03-10 20:06 ` Austin.Bolen
2020-03-10 20:41 ` Kuppuswamy Sathyanarayanan
2020-03-10 20:49 ` Austin.Bolen
2020-03-11 14:45 ` Bjorn Helgaas
2020-03-11 15:19 ` Austin.Bolen
2020-03-11 17:12 ` Bjorn Helgaas
2020-03-11 17:27 ` Austin.Bolen
2020-03-11 20:33 ` Bjorn Helgaas
2020-03-11 21:25 ` Kuppuswamy Sathyanarayanan
2020-03-11 21:53 ` Austin.Bolen
2020-03-11 22:11 ` Kuppuswamy Sathyanarayanan
2020-03-11 22:23 ` Bjorn Helgaas
2020-03-11 23:07 ` Kuppuswamy Sathyanarayanan
2020-03-12 19:53 ` Bjorn Helgaas
2020-03-12 21:02 ` Austin.Bolen
2020-03-12 21:29 ` Kuppuswamy Sathyanarayanan
2020-03-12 21:52 ` Bjorn Helgaas
2020-03-12 22:02 ` Kuppuswamy Sathyanarayanan
2020-03-12 22:36 ` Bjorn Helgaas
2020-03-12 21:59 ` Kuppuswamy Sathyanarayanan
2020-03-12 22:32 ` Bjorn Helgaas
2020-03-13 6:22 ` Kuppuswamy, Sathyanarayanan
2020-03-13 19:28 ` Bjorn Helgaas [this message]
2020-03-13 20:26 ` Kuppuswamy Sathyanarayanan
2020-03-19 23:03 ` Bjorn Helgaas
2020-03-19 23:20 ` Kuppuswamy, Sathyanarayanan
2020-03-11 22:13 ` Bjorn Helgaas
2020-03-11 22:41 ` Kuppuswamy Sathyanarayanan
2020-03-11 18:12 ` Kuppuswamy Sathyanarayanan
2020-03-11 22:05 ` Bjorn Helgaas
2020-03-04 2:36 ` [PATCH v17 10/12] PCI/DPC: Export DPC error recovery functions sathyanarayanan.kuppuswamy
2020-03-17 14:43 ` Christoph Hellwig
2020-03-04 2:36 ` [PATCH v17 11/12] PCI/DPC: Add Error Disconnect Recover (EDR) support sathyanarayanan.kuppuswamy
2020-03-06 3:47 ` Bjorn Helgaas
2020-03-06 6:32 ` Kuppuswamy, Sathyanarayanan
2020-03-06 21:00 ` Bjorn Helgaas
2020-03-06 22:42 ` Kuppuswamy Sathyanarayanan
2020-03-06 23:23 ` Bjorn Helgaas
2020-03-07 0:19 ` Kuppuswamy Sathyanarayanan
2020-03-04 2:36 ` [PATCH v17 12/12] PCI/ACPI: Enable EDR support sathyanarayanan.kuppuswamy
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=20200313192816.GA127896@google.com \
--to=helgaas@kernel.org \
--cc=Austin.Bolen@dell.com \
--cc=ashok.raj@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=oohall@gmail.com \
--cc=ruscur@russell.cc \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=sbobroff@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;
as well as URLs for NNTP newsgroup(s).