[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5 2/4] target-s390x: Migrate to new nmi_monitor
From: |
Cornelia Huck |
Subject: |
Re: [Qemu-devel] [PATCH v5 2/4] target-s390x: Migrate to new nmi_monitor_handler() CPU callback |
Date: |
Tue, 10 Jun 2014 13:48:23 +0200 |
On Tue, 10 Jun 2014 16:18:01 +1000
Alexey Kardashevskiy <address@hidden> wrote:
> This defines a nmi_monitor_handler() callback for s390 CPU class.
>
> This removes #ifdef s390 branch in qmp_inject_nmi so new s390's
> nmi_monitor_handler() callback is going to be used for NMI.
>
> Since nmi_monitor_handler()-calling code is platform independent,
> CPUState::cpu_index is used instead of S390CPU::env.cpu_num.
> There should not be any change in behaviour as both @cpu_index and
> @cpu_num are global CPU numbers.
>
> Also, s390_cpu_restart() takes care of preforming operations in
> the specific CPU thread so no extra measure is required here either.
>
> Since the only error s390_cpu_restart() can return is ENOSYS, convert
> it to QERR_UNSUPPORTED.
That's an improvement over the current check for == -1.
>
> Signed-off-by: Alexey Kardashevskiy <address@hidden>
> ---
> Changes:
> v5:
> * added ENOSYS -> QERR_UNSUPPORTED, qapi/qmp/qerror.h was added for this
>
> v4:
> * s/\<nmi\>/nmi_monitor_handler/
>
> v3:
> * now contains both old code removal and new code insertion, easier to
> track changes
>
> ---
> Is there any good reason to have @cpu_num in addition to @cpu_index?
> Just asking :)
> ---
> cpus.c | 14 --------------
> target-s390x/cpu.c | 9 +++++++++
> 2 files changed, 9 insertions(+), 14 deletions(-)
>
Acked-by: Cornelia Huck <address@hidden>