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 interesting. 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 [0] http://patchwork.ozlabs.org/patch/670781/ [1] http://patchwork.ozlabs.org/patch/670782/ 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