[v2 09/12] powerpc/mce: Enable MCE notifiers in external modules

Nicholas Piggin npiggin at gmail.com
Thu Jul 4 12:36:18 AEST 2019

Reza Arbab's on July 4, 2019 3:20 am:
> 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?

If we tested for KVM guest first, and went through and marked (maybe
in a paca flag) everywhere else that put the MMU into a bad / non-host
state, and had the notifiers use the machine check stack, then it
would be possible to enable MMU here.

Hmm, testing for IR|DR after testing for KVM guest might actually be
enough without requiring changes outside the machine check handler...
Actually no that may not quite work because the handler could take a
SLB miss and it might have been triggered inside the SLB miss handler.

All in all I'm pretty against turning on MMU in the MCE handler

> 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).

What users are there? Do they do any significant amount of logic that
can not be moved to vmlinux?


More information about the Linuxppc-dev mailing list