On Tue, Mar 17, 2020 at 12:26:13AM +1000, Nicholas Piggin wrote: > Linux kernels call "ibm,nmi-interlock" in their system reset handlers > contrary to PAPR. Returning an error because the CPU does not hold the > interlock here causes Linux to print warning messages. PowerVM returns > success in this case, so do the same for now. > > Signed-off-by: Nicholas Piggin <npig...@gmail.com>
Applied, thanks.
> ---
> hw/ppc/spapr_rtas.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
> index 521e6b0b72..9fb8c8632a 100644
> --- a/hw/ppc/spapr_rtas.c
> +++ b/hw/ppc/spapr_rtas.c
> @@ -461,8 +461,18 @@ static void rtas_ibm_nmi_interlock(PowerPCCPU *cpu,
> }
>
> if (spapr->fwnmi_machine_check_interlock != cpu->vcpu_id) {
> - /* The vCPU that hit the NMI should invoke "ibm,nmi-interlock" */
> - rtas_st(rets, 0, RTAS_OUT_PARAM_ERROR);
> + /*
> + * The vCPU that hit the NMI should invoke "ibm,nmi-interlock"
> + * This should be PARAM_ERROR, but Linux calls "ibm,nmi-interlock"
> + * for system reset interrupts, despite them not being interlocked.
> + * PowerVM silently ignores this and returns success here. Returning
> + * failure causes Linux to print the error "FWNMI: nmi-interlock
> + * failed: -3", although no other apparent ill effects, this is a
> + * regression for the user when enabling FWNMI. So for now, match
> + * PowerVM. When most Linux clients are fixed, this could be
> + * changed.
> + */
> + rtas_st(rets, 0, RTAS_OUT_SUCCESS);
> return;
> }
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
