[v2 09/12] powerpc/mce: Enable MCE notifiers in external modules
Reza Arbab
arbab at linux.ibm.com
Thu Jul 4 03:20:09 AEST 2019
On Tue, Jul 02, 2019 at 04:17:11PM +1000, Nicholas Piggin wrote:
>Santosh Sivaraj's on July 2, 2019 3:19 pm:
>> --- a/arch/powerpc/kernel/exceptions-64s.S
>> +++ b/arch/powerpc/kernel/exceptions-64s.S
>> @@ -458,6 +458,12 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
>> bl machine_check_early
>> std r3,RESULT(r1) /* Save result */
>>
>> + /* Notifiers may be in a module, so enable virtual addressing. */
>> + mfmsr r11
>> + ori r11,r11,MSR_IR
>> + ori r11,r11,MSR_DR
>> + mtmsr r11
>
>Can't do this, we could take a machine check somewhere the MMU is
>not sane (in fact the guest early mce handling that was added recently
>should not be enabling virtual mode either, which needs to be fixed).
Rats. So in machine_check_handle_early() there are two options; either
1. The mc is unhandled/unrecoverable. Stay in real mode, proceed to
unrecover_mce(), the fatal path of no return (panic, reboot, etc).
2. The mc is handled/recovered. Return from MCE where any further action
can be done by processing the machine check event workqueue. Am I
understanding you correctly that this is the absolute earliest we can
get back to virtual mode?
Since the notifier chain is actually part of the decision between (1)
and (2), it's a hard limitation then that callbacks be in real address
space. Is there any way to structure things so that's not the case?
Luckily this patch isn't really necessary for memcpy_mcsafe(), but we
have a couple of other potential users of the notifier from external
modules (so their callbacks would require virtual mode).
--
Reza Arbab
More information about the Linuxppc-dev
mailing list