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
