| Message ID | 1484533171.11927.24.camel@kernel.crashing.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
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 <benh@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.
On Mon, 2017-01-16 at 21:37 +0530, Balbir Singh wrote: > ?? > > <snip> > > > @@ -39,7 +40,2 Ah evolution bug ... fixed upstream but fix hasn't made it to Fedora yet. I'll attach in the meantime. Cheers, Ben.
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 static void icp_opal_teardown_cpu(void) { @@ -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(); +} + +static unsigned int icp_opal_get_xirr(void) +{ + unsigned int kvm_xirr; + __be32 hw_xirr; + int64_t rc; + + /* Handle an interrupt latched by KVM first */ + kvm_xirr = kvmppc_get_xics_latch(); + if (kvm_xirr) + return kvm_xirr; + + /* Then ask OPAL */ + rc = opal_int_get_xirr(&hw_xirr, false); + if (rc < 0) + return 0; + return be32_to_cpu(hw_xirr); } static unsigned int icp_opal_get_irq(void) @@ -47,12 +67,8 @@ static unsigned int icp_opal_get_irq(void) unsigned int xirr; unsigned int vec; unsigned int irq; - int64_t rc; - rc = opal_int_get_xirr(&xirr, false); - if (rc < 0) - return 0; - xirr = be32_to_cpu(xirr); + xirr = icp_opal_get_xirr(); vec = xirr & 0x00ffffff; if (vec == XICS_IRQ_SPURIOUS) return 0; @@ -67,7 +83,8 @@ static unsigned int icp_opal_get_irq(void) xics_mask_unknown_vec(vec); /* We might learn about it later, so EOI it */ - opal_int_eoi(xirr); + if (opal_int_eoi(xirr) > 0) + force_external_irq_replay(); return 0; }
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 <benh@kernel.crashing.org> --- arch/powerpc/sysdev/xics/icp-opal.c | 31 ++++++++++++++++++++++++------- 1 file changed, 24 insertions(+), 7 deletions(-)