From: Reza Arbab <arbab@linux.ibm.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: Santosh Sivaraj <santosh@fossix.org>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Mahesh Salgaonkar <mahesh@linux.ibm.com>,
Chandan Rajendra <chandan@linux.vnet.ibm.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [v2 09/12] powerpc/mce: Enable MCE notifiers in external modules
Date: Wed, 3 Jul 2019 12:20:09 -0500 [thread overview]
Message-ID: <20190703172008.aiyofnhqgbzi6ckw@arbab-vm> (raw)
In-Reply-To: <1562047959.5y756f60wn.astroid@bobo.none>
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
next prev parent reply other threads:[~2019-07-03 17:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-02 5:19 [v2 00/12] powerpc: implement machine check safe memcpy Santosh Sivaraj
2019-07-02 5:19 ` [v2 01/12] powerpc/mce: Make machine_check_ue_event() static Santosh Sivaraj
2019-07-02 5:19 ` [v2 02/12] powerpc/mce: Bug fixes for MCE handling in kernel space Santosh Sivaraj
2019-07-02 5:19 ` [v2 03/12] powerpc/mce: Add MCE notification chain Santosh Sivaraj
2019-07-02 14:55 ` Reza Arbab
2019-07-02 5:19 ` [v2 04/12] powerpc/mce: Move machine_check_ue_event() call Santosh Sivaraj
2019-07-02 5:19 ` [v2 05/12] powerpc/mce: Allow notifier callback to handle MCE Santosh Sivaraj
2019-07-02 5:19 ` [v2 06/12] powerpc/mce: Add fixup address to UE events Santosh Sivaraj
2019-07-02 5:19 ` [v2 07/12] powerpc/memcpy: Add memcpy_mcsafe for pmem Santosh Sivaraj
2019-07-02 5:19 ` [v2 08/12] powerpc/mce: Handle memcpy_mcsafe() Santosh Sivaraj
2019-07-02 5:19 ` [v2 09/12] powerpc/mce: Enable MCE notifiers in external modules Santosh Sivaraj
2019-07-02 6:17 ` Nicholas Piggin
2019-07-02 9:33 ` Mahesh Jagannath Salgaonkar
2019-07-03 17:20 ` Reza Arbab [this message]
2019-07-04 2:36 ` Nicholas Piggin
2019-07-05 2:50 ` Reza Arbab
2019-07-05 5:29 ` Nicholas Piggin
2019-07-08 15:23 ` Reza Arbab
2019-07-02 5:19 ` [v2 10/12] powerpc/memcpy_mcsafe: return remaining bytes Santosh Sivaraj
2019-07-02 5:19 ` [v2 11/12] powerpc: add machine check safe copy_to_user Santosh Sivaraj
2019-07-02 5:19 ` [v2 12/12] powerpc/64s: Save r13 in machine_check_common_early Santosh Sivaraj
2019-07-02 6:19 ` Nicholas Piggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190703172008.aiyofnhqgbzi6ckw@arbab-vm \
--to=arbab@linux.ibm.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=chandan@linux.vnet.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mahesh@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=santosh@fossix.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).