[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