[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RESEND RFC PATCH v2 2/2] target/arm: Support NMI injection

From: Peter Maydell
Subject: Re: [RESEND RFC PATCH v2 2/2] target/arm: Support NMI injection
Date: Thu, 13 Feb 2020 11:11:32 +0000

On Wed, 5 Feb 2020 at 11:06, Gavin Shan <address@hidden> wrote:
> This supports QMP/HMP "nmi" command by injecting SError interrupt to
> guest, which is expected to crash with that. Currently, It's supported
> on two CPU models: "host" and "max".
> Signed-off-by: Gavin Shan <address@hidden>
> ---
>  hw/arm/virt.c          | 18 ++++++++++++++++
>  target/arm/cpu-qom.h   |  1 +
>  target/arm/cpu.c       | 48 ++++++++++++++++++++++++++++++++++++++++++
>  target/arm/cpu64.c     | 25 ++++++++++++++++++----
>  target/arm/internals.h |  8 +++++++
>  5 files changed, 96 insertions(+), 4 deletions(-)

A few quick general notes:

(1) as I mentioned on the cover letter, the mechanism
for injecting an SError/async external abort into the
CPU should be a qemu_irq line, like FIQ/IRQ, not a
special-purpose method on the CPU object.

(2) for function naming, there's a dividing line between:
 * code that implements the (unfortunately x86-centric)
   monitor command named "nmi"; these functions can have
   names with 'nmi' in them
 * code which implements the actual mechanism of 'deliver
   an SError to the CPU'; these functions should not
   have 'nmi' in the name or mention nmi, because nmi is
   not a concept in the Arm architecture

(3) Before we expose 'nmi' to users as something that
delivers an SError, we need to think about the interactions
with RAS, because currently we also use SError to say
"there was an error in the host memory you're using",
and we might in future want to use SError for proper
emulated RAS. We don't want to paint ourselves into a
corner by grabbing SError exclusively for 'nmi'.

-- PMM

reply via email to

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