mca: Allow for passing ECC error record to memory controller driver.

[stevek]

Summary

Added (de)registration functions for memory controller driver to be
notified when ECC errors occur. This allows for decoding of the
specific error by the driver.

Sponsored by: Juniper Networks, Inc.
Obtained from: Semihalf

[mav]

sys/x86/x86/mca.c

448

mca_func check asks to be under the lock.

656

For "do some more work" we have too many conditions above when entering this function.

[stevek]

Updated based on review comments

[mav]

I have no objections, if it is useful.

[stevek]

Using atomics for fetching/modifying the decode function pointer

[mav]

I wonder if there is any real architecture where pointer load/store is non-atomic. For things that are going to be executed between once and never it feels like you are over-engineering it. :)

[stevek]

In D45072#1028956, @mav wrote:

I wonder if there is any real architecture where pointer load/store is non-atomic. For things that are going to be executed between once and never it feels like you are over-engineering it. :)

We had discussions about this in D39661, which I had not originally noticed that when I submitted this one it went to a new review.
I'm okay with removing the atomics, since it's usually going to be a one-and-done registration.

[markj]

I don't see a reason to use atomics for the operations which happen under mca_lock. It is ok to assume that unqualified aligned pointer loads and stores are atomic; at least, we make this assumption pervasively in the kernel. It is nonetheless reasonable to use atomic_load_ptr() for the unlocked load in mca_log().

sys/x86/x86/mca.c

436

This should be atomic_store_ptr(), not atomic_set_ptr(). But see my other comment.