Currently, if you attempt to kexec into a new kernel from a machine with a
CAPI card and the cxl driver loaded, you are going to have an exceedingly
bad time. It turns out that the hardware doesn't really cope very well with
going through the standard Linux PCI initialisation process while a PHB is
still in CAPI mode. Checkstops everywhere!

I've submitted RFC patches for skiboot[0][1] to disable CAPI mode when we
do a complete reset on a PHB. This series ensures that when we enter the
new kernel, we ask skiboot to do a complete reset on any PHBs that have
been left in CAPI mode before we initialise everything.

At this stage, I haven't thought too hard about getting to the point where
we can do this after Linux has booted for stuff like PCI hotplug...
triggering a creset after the Linux EEH handling is all set up can get

This has only gotten the very lightest of testing - I've kexec-ed quite a
few times with no real problems, and I've run some basic CAPI tests that
don't seem to fail too much more than they normally fail. It does look like
we get spammed with a tonne of HMIs and frozen PE messages in the skiboot
log, not sure how bad this is.

Thanks to Vaibhav Jain (who made a previous attempt at this), Mikey
Neuling, Ben Herrenschmidt, Gavin Shan, Bill Daly and JT Kellington for
advice on various bits of this.



Andrew Donnellan (3):
  powerpc/powernv: fix comment style and spelling
  powerpc/powernv: add opal_pci_get_phb_capi_mode() call
  powerpc/powernv: reset any PHBs in CAPI mode during initialisation

 arch/powerpc/include/asm/opal-api.h            |  3 ++-
 arch/powerpc/include/asm/opal.h                |  1 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |  1 +
 arch/powerpc/platforms/powernv/pci-ioda.c      | 17 ++++++++++++++---
 4 files changed, 18 insertions(+), 4 deletions(-)

base-commit: 024c7e3756d8a42fc41fe8a9488488b9b09d1dcc
git-series 0.8.10

Reply via email to