qemu-devel
[Top][All Lists]
Advanced

[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>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]