From: Daniel Axtens <dja@axtens•net>
To: Michael Ellerman <mpe@ellerman•id.au>, linuxppc-dev@lists•ozlabs.org
Cc: aneesh.kumar@linux•ibm.com
Subject: Re: [PATCH 2/6] powerpc/pseries: Add key to flags in pSeries_lpar_hpte_updateboltedpp()
Date: Tue, 16 Feb 2021 16:39:45 +1100 [thread overview]
Message-ID: <87tuqca7vi.fsf@linkitivity.dja.id.au> (raw)
In-Reply-To: <20210211135130.3474832-2-mpe@ellerman.id.au>
Michael Ellerman <mpe@ellerman•id.au> writes:
> The flags argument to plpar_pte_protect() (aka. H_PROTECT), includes
> the key in bits 9-13, but currently we always set those bits to zero.
>
> In the past that hasn't been a problem because we always used key 0
> for the kernel, and updateboltedpp() is only used for kernel mappings.
>
> However since commit d94b827e89dc ("powerpc/book3s64/kuap: Use Key 3
> for kernel mapping with hash translation") we are now inadvertently
> changing the key (to zero) when we call plpar_pte_protect().
>
> That hasn't broken anything because updateboltedpp() is only used for
> STRICT_KERNEL_RWX, which is currently disabled on 64s due to other
> bugs.
>
> But we want to fix that, so first we need to pass the key correctly to
> plpar_pte_protect(). In the `newpp` value the low 3 bits of the key
> are already in the correct spot, but the high 2 bits of the key need
> to be shifted down.
>
> Fixes: d94b827e89dc ("powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation")
> Signed-off-by: Michael Ellerman <mpe@ellerman•id.au>
> ---
> arch/powerpc/platforms/pseries/lpar.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
> index 764170fdb0f7..8bbbddff7226 100644
> --- a/arch/powerpc/platforms/pseries/lpar.c
> +++ b/arch/powerpc/platforms/pseries/lpar.c
> @@ -976,11 +976,13 @@ static void pSeries_lpar_hpte_updateboltedpp(unsigned long newpp,
> slot = pSeries_lpar_hpte_find(vpn, psize, ssize);
> BUG_ON(slot == -1);
>
> - flags = newpp & 7;
> + flags = newpp & (HPTE_R_PP | HPTE_R_N);
> if (mmu_has_feature(MMU_FTR_KERNEL_RO))
> /* Move pp0 into bit 8 (IBM 55) */
> flags |= (newpp & HPTE_R_PP0) >> 55;
>
> + flags |= ((newpp & HPTE_R_KEY_HI) >> 48) | (newpp & HPTE_R_KEY_LO);
> +
I'm really confused about how these bits are getting packed into the
flags parameter. It seems to match how they are unpacked in
kvmppc_h_pr_protect, but I cannot figure out why they are packed in that
order, and the LoPAR doesn't seem especially illuminating on this topic
- although I may have missed the relevant section.
Kind regards,
Daniel
> lpar_rc = plpar_pte_protect(flags, slot, 0);
>
> BUG_ON(lpar_rc != H_SUCCESS);
> --
> 2.25.1
next prev parent reply other threads:[~2021-02-16 5:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-11 13:51 [PATCH 1/6] powerpc/mm/64s: Add _PAGE_KERNEL_ROX Michael Ellerman
2021-02-11 13:51 ` [PATCH 2/6] powerpc/pseries: Add key to flags in pSeries_lpar_hpte_updateboltedpp() Michael Ellerman
2021-02-16 5:39 ` Daniel Axtens [this message]
2021-02-18 23:25 ` Michael Ellerman
2021-02-11 13:51 ` [PATCH 3/6] powerpc/64s: Use htab_convert_pte_flags() in hash__mark_rodata_ro() Michael Ellerman
2021-02-16 5:50 ` Daniel Axtens
2021-02-11 13:51 ` [PATCH 4/6] powerpc/mm/64s/hash: Factor out change_memory_range() Michael Ellerman
2021-02-19 2:08 ` Daniel Axtens
2021-03-16 6:30 ` Michael Ellerman
2021-02-11 13:51 ` [PATCH 5/6] powerpc/mm/64s/hash: Add real-mode change_memory_range() for hash LPAR Michael Ellerman
2021-02-11 23:16 ` Nicholas Piggin
2021-03-20 13:04 ` Michael Ellerman
2021-03-22 2:56 ` Nicholas Piggin
2021-02-12 0:36 ` Nicholas Piggin
2021-03-16 6:40 ` Michael Ellerman
2021-03-22 3:09 ` Nicholas Piggin
2021-03-22 9:07 ` Michael Ellerman
2021-02-19 2:43 ` Daniel Axtens
2021-03-19 11:56 ` Michael Ellerman
2021-02-11 13:51 ` [PATCH 6/6] powerpc/mm/64s: Allow STRICT_KERNEL_RWX again Michael Ellerman
2021-04-10 14:28 ` [PATCH 1/6] powerpc/mm/64s: Add _PAGE_KERNEL_ROX Michael Ellerman
2021-04-19 5:17 ` Michael Ellerman
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=87tuqca7vi.fsf@linkitivity.dja.id.au \
--to=dja@axtens$(echo .)net \
--cc=aneesh.kumar@linux$(echo .)ibm.com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=mpe@ellerman$(echo .)id.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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