On Sun, Jan 15, 2017 at 08:19:31PM -0600, Benjamin Herrenschmidt wrote: > The icp-opal call is missing the code from icp-native to recover > interrupts snatched by KVM. Without that, when running KVM, we can > get into a situation where an interrupt is lost and the CPU stuck > with an elevated CPPR. > > Also harden replay by always checking the return from opal_int_eoi > > Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> > --- > arch/powerpc/sysdev/xics/icp-opal.c | 31 ++++++++++++++++++++++++------- > 1 file changed, 24 insertions(+), 7 deletions(-) > > diff --git a/arch/powerpc/sysdev/xics/icp-opal.c > b/arch/powerpc/sysdev/xics/icp-opal.c > index d38e86f..60c5765 100644 > --- a/arch/powerpc/sysdev/xics/icp-opal.c > +++ b/arch/powerpc/sysdev/xics/icp-opal.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include >
?? <snip> > @@ -39,7 +40,26 @@ static void icp_opal_flush_ipi(void) > * Should we be flagging idle loop instead? > * Or creating some task to be scheduled? > */ > - opal_int_eoi((0x00 << 24) | XICS_IPI); > + if (opal_int_eoi((0x00 << 24) | XICS_IPI) > 0) > + force_external_irq_replay(); > +} Shouldn't we also update kvm bits on icp_native_ipi_action and icp_native_cause_ipi? Balbir Singh.
