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?
Yes. > 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 anywhere. > 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? Thanks, Nick
