Date:	Thu, 10 Dec 2015 11:38:47 +1100
From:	Stewart Smith <stewart@...ux.vnet.ibm.com>
To:	Daniel Axtens <dja@...ens.net>,
	Denis Kirjanov <kda@...ux-powerpc.org>
Cc:	linuxppc-dev@...abs.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Mahesh J Salgaonkar <mahesh.salgaonkar@...ibm.com>
Subject: Re: [PATCH] selftests/powerpc: Add script to test HMI functionality

Daniel Axtens <dja@...ens.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 :)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists