All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stewart Smith <stewart@linux.vnet.ibm.com>
To: Daniel Axtens <dja@axtens.net>, Denis Kirjanov <kda@linux-powerpc.org>
Cc: linuxppc-dev@ozlabs.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Mahesh J Salgaonkar <mahesh.salgaonkar@in.ibm.com>
Subject: Re: [PATCH] selftests/powerpc: Add script to test HMI functionality
Date: Thu, 10 Dec 2015 11:38:47 +1100	[thread overview]
Message-ID: <87vb87b0iw.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <87h9jrxkg0.fsf@gamma.ozlabs.ibm.com>

Daniel Axtens <dja@axtens.net> writes:
> I just realised I sent my reply to Denis not the list - apologies. This
> info goes for v2 as well.
>
>   > Could you explain why it's useful, and what it's useful for. Moreover,
>   > it's POWER8 feature, right?
>
>   I'm not sure whether you're asking about the script or HMIs. Explaining
>   HMIs helps make sense of the script, so I'll start there.
>
>   HMIs are a class of interrupt or exception that, broadly speaking,
>   require the hypervisor to intervene to 'do something'. They are (very
>   lightly) documented in the POWER ISA, which is available on the
>   OpenPOWER website. That file doesn't do a particuarly good job of
>   explaining what can trigger an HMI, because that's a Book IV question.
>
>   So, while I can't point you to documentation about what might cause an
>   HMI, I can point you to some source code. Here goes:
>
>   An HMI will (per the ISA) cause execution to jump to
>   0x0000 0000 0000 0E60. Through some asm and C you end up calling
>   ppc_md.hmi_exception_early() and then possibly
>   ppc_md.handle_hmi_expection(). This is only defined on PowerNV, where
>   they point to opal_hmi_exception_early() and
>   opal_handle_hmi_exception() respectively.
>
>   The early exception calls into opal through opal_handle_hmi, which is an
>   OPAL call (OPAL_HANDLE_HMI). skiboot/core/hmi.c lists the contents of
>   the HMER (Hypervisor Maintenance Exception Register), which identifies
>   the actual cause of the HMI. You can find the list in the skiboot repo
>   on github, including the action that will be taken:
>   https://github.com/open-power/skiboot/blob/master/core/hmi.c
>   The rest of the file fleshes out the mechanics of HMIs: for example,
>   where they are caused by the failure of a POWER8 co-processor such as
>   CAPI or NX.
>
>   Some HMIs are relayed by Skiboot to Linux by sending an OPAL_MSG_HMI_EVT
>   to Linux. This triggers off some further processing which causes a
>   message to be printed in dmesg. The relevant file here is
>   platforms/powernv/opal-hmi.c
>
>   The script, therefore, is useful because:
>    - HMIs are an exceptional/error condition that is not hit in normal
>      operation. Indeed, without the xscom commands in this script
>      (or a CAPI card), it's almost impossible to hit them.
>    - HMIs involve communications between Skiboot and Linux, involve
>      touching the PACA, and generally work in an area that is prone to
>      bugs, so testing them is especially valuable.
>    - The script is carefully calibrated to send HMIs that trigger a
>      message in dmesg but which don't checkstop the machine.
>
>   To answer your final question, I'm not entirely sure if HMIs are POWER8
>   specific. I suspect they've been around for a lot longer, but maybe
>   someone who's been around IBM chips for longer than me could clarify this.

Adding this to doc/ somewhere in kernel and/or skiboot would be
great. There's a skiboot doc/hmi.txt that's begging for a patch, you
know, creating it :)

      reply	other threads:[~2015-12-10  0:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-18  4:43 [PATCH] selftests/powerpc: Add script to test HMI functionality Daniel Axtens
2015-11-18 11:33 ` Denis Kirjanov
2015-12-09 23:37   ` Daniel Axtens
2015-12-10  0:38     ` Stewart Smith [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vb87b0iw.fsf@linux.vnet.ibm.com \
    --to=stewart@linux.vnet.ibm.com \
    --cc=dja@axtens.net \
    --cc=kda@linux-powerpc.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mahesh.salgaonkar@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.