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 :)
prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).