On 7/28/26 10:47, Srikar Dronamraju wrote:
* Gou Hao <[email protected]> [2026-07-27 18:42:13]:
static void __init pnv_smp_probe(void)
{
- if (xive_enabled())
- xive_smp_probe();
- else
+ if (xive_enabled()) {
+ if (xive_smp_probe() < 0)
+ return;
+ } else {
If xive_smp_probe() fails and we return from here, what is the IPI mechanism
that is going to be used?
Before the patch, we were not configured for IPI and we would fail.
Now we have not configured IPI mechanism, so what are the consequences?
Thank you for your review.
current approach: If xive_smp_probe() fails, smp_ops->cause_ipi remains
NULL (patch 0004 defers the assignment). The IPI path
(smp_muxed_ipi_message_pass) has a NULL check that silently drops the
IPI. This means SMP won't function, but that's preferable to the current
use-after-free crash.
Should we try disable xive_enabled() and try xics_smp_probe() instead?
When xive_enabled() is true, the entire interrupt subsystem has already
been committed to XIVE in xive_init_host(). XICS fallback may need more
than just disabling xive_enabled() and calling xics_smp_probe().
Full XIVE → XICS fallback is theoretically possible — the kexec path
already demonstrates this (e.g., xive_shutdown() on PowerNV calls
opal_xive_reset(OPAL_XIVE_MODE_EMU), and pSeries has H_INT_RESET). After
reverting XIVE, one could call xics_init() + xics_smp_probe() to set up
XICS completely.
Implementing a safe, complete fallback would require careful sequencing
and likely an xive_exit() counterpart — this is a significantly larger
change that is beyond the scope of this series, which focuses on
removing __GFP_NOFAIL and fixing the use-after-free.
--
Thanks,
Gou Hao
