x86: Keep cumulative MCA statistics in the kernel

[jtl]

Summary

Keeping cumulative MCA statistics in the kernel provides a way for users to get an accurate count of various kinds of errors reported by the CPU.

After ca8929d2a3e9b9df31d2e487377f99d7c39aa01d, it is possible that the kernel will drop the record of some MCA interrupts. Moreover, this provides a cheaper interface to obtain statistics if that is the only reason a user is processing MCA logs.

Test Plan

This is a lightly updated version of a patch which has been in use within Netflix for a while.

[jtl]

If anyone is planning to review this (or if I should ask more people), let me know. Otherwise, I will probably just commit this soon. AFAICT, this is fairly innocuous (new feature with low risk of breaking existing things). But, there is a reason we get these things reviewed...

[markj]

It'd be nice to document this somewhere, but sadly we don't appear to have an mca.4.

sys/x86/x86/mca.c

137

We've generally been avoiding adding new uses of volatile to denote variables accessed using atomic(9). I'd instead add a short comment explaining the synchronization protocol for this array.

652

Was it intentional to include both an assertion and runtime check? If so, something like this would be a bit cleaner IMO:

if (event_type < 0 || event_type >= MCA_T_COUNT) {
     KASSERT(0, ("%s invalid event type (%d)", ...));
     event_type = MCA_T_UNKNOWN;
}

[jtl]

Thanks for the review! I agree on the documentation comment.

sys/x86/x86/mca.c

137

OK, thanks. I didn't know that. We may want to remove volatile from the prototypes in atomic(9). I'll change it and add a comment.

652

Yes, it was intentional, in a belt-and-suspenders sort of way. If anyone adds a new event type and tests their code with a DEBUG kernel, they should hit the assertion as a reminder to update the stats array. If that doesn't happen, the runtime check avoids an out-of-bounds write.

I like your update; I will adopt it.

[jtl]

incorporating review feedback