Hi Boris,

On 04/10/2018 18:34, Borislav Petkov wrote:

On Wed, Oct 03, 2018 at 06:50:36PM +0100, James Morse wrote:

quoted

I'm all in favour of letting the compiler work it out, but the existing ghes
code has #ifdef/#else all over the place. This is 'keeping the style'.

Yeah, but this "style" is not the optimal one and we should
simplify/clean up and fix this thing.

Swapping the order of your statements here:

quoted

The ACPI spec has four ~NMI notifications, so far the support for
these in Linux has been selectable separately.

Yes, but: distro kernels end up enabling all those options anyway and
distro kernels are 90-ish% of the setups. Which means, this will get
enabled anyway and this additional Kconfig symbol is simply going to be
one automatic reply "Yes".

So let's build it in by default and if someone complains about it, we
can always carve it out. But right now I don't see the need for the
unnecessary separation...

Ripping out the existing #ifdefs and replacing them with IS_ENABLED() would let
the compiler work out the estatus stuff is unused, and saves us describing the
what-uses-it logic in Kconfig.

But this does expose the x86 nmi stuff on arm64, which doesn't build today.
Dragging NMI_HANDLED and friends up to the 'linux' header causes a fair amount
of noise under arch/x86 (include the new header in 22 files). Adding dummy
declarations to arm64 fixes this, and doesn't affect the other architectures
that have an asm/nmi.h

Alternatively we could leave {un,}register_nmi_handler() under
CONFIG_HAVE_ACPI_APEI_NMI. I think we need to keep the NOTIFY_NMI kconfig symbol
around, as its one of the two I can't work out how to fix without the TLBI-IPI.


Thanks,

James