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: Thu, 4 Jul 2019 21:50:42 -0500 [thread overview]
Message-ID: <20190705025042.nnov5s45jc4jd5ld@arbab-vm> (raw)
In-Reply-To: <1562207031.05iwu5t2xm.astroid@bobo.none>
On Thu, Jul 04, 2019 at 12:36:18PM +1000, Nicholas Piggin wrote:
>Reza Arbab's on July 4, 2019 3:20 am:
>> 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.
Hey, fair enough. Just making sure there really isnt't any room to make
things work the way I was trying.
>> 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?
One I had in mind was the NVIDIA driver. When taking a UE from defective
GPU memory, it could use the notifier to save the bad address to a
blacklist in their nvram. Not so much recovering the machine check, just
logging before the system reboots.
The other user is a prototype driver for the IBM Research project we had
a talk about offline a while back.
We can make this patchset work for memcpy_mcsafe(), but I think it's
back to the drawing board for the others.
--
Reza Arbab
next prev parent reply other threads:[~2019-07-05 2:52 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
2019-07-04 2:36 ` Nicholas Piggin
2019-07-05 2:50 ` Reza Arbab [this message]
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=20190705025042.nnov5s45jc4jd5ld@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