From: Nicholas Piggin <npiggin@gmail.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org,
Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH] powerpc/book3s64/kuap: SPRN_AMR modification need CSI instructions before and after
Date: Wed, 22 Apr 2020 17:45:33 +1000 [thread overview]
Message-ID: <1587541260.w3jfzesvph.astroid@bobo.none> (raw)
In-Reply-To: <87y2qqhc2w.fsf@mpe.ellerman.id.au>
Excerpts from Michael Ellerman's message of April 20, 2020 5:04 pm:
> Nicholas Piggin <npiggin@gmail.com> writes:
>> Excerpts from Nicholas Piggin's message of April 20, 2020 10:17 am:
>>> Excerpts from Aneesh Kumar K.V's message of April 19, 2020 11:53 pm:
>>>> As per the ISA, context synchronizing instructions is needed before and after
>>>> SPRN_AMR update. Use isync before and the CSI after is implied by the rfid
>>>> that we will use to switch to a new context.
>>>
>>> Not entirely sure if we need this. This will restore AMR to more
>>> permissive, so if it executes ahead of a stray load from this
>>> context, it won't make it fault.
>
> I thought we'd convinced ourselves it didn't matter in practice due to
> the proximity of the entry/exit.
I don't remember exactly. We can always drop the isync from the side
that pairs with an entry or exit.
If we drop it from the other side, what it means in theory is it could
float past some of the accesses we're doing in the interrupt context
that we thought were protected. So we won't take faults, but it's
possible we would let through a user access.
I think it's likey that we'd end up executing the mtspr before anything
much can take advantage of it, but you never know, and I guess the
problem is it becomes impossile to audit and be sure.
Thanks,
Nick
prev parent reply other threads:[~2020-04-22 7:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-19 13:53 [PATCH] powerpc/book3s64/kuap: SPRN_AMR modification need CSI instructions before and after Aneesh Kumar K.V
2020-04-20 0:17 ` Nicholas Piggin
2020-04-20 1:12 ` Nicholas Piggin
2020-04-20 7:04 ` Michael Ellerman
2020-04-22 7:45 ` Nicholas Piggin [this message]
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=1587541260.w3jfzesvph.astroid@bobo.none \
--to=npiggin@gmail.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
/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).