From: Suzuki K Poulose <suzuki.poulose@arm•com>
To: Mark Brown <broonie@kernel•org>
Cc: Catalin Marinas <catalin.marinas@arm•com>,
Will Deacon <will@kernel•org>,
linux-arm-kernel@lists•infradead.org
Subject: Re: [PATCH v2 2/2] arm64: Don't use KPTI where we have E0PD
Date: Thu, 10 Oct 2019 11:24:55 +0100 [thread overview]
Message-ID: <2d53ed87-34f3-33e1-5501-77895662c47a@arm.com> (raw)
In-Reply-To: <20191009175205.GN2036@sirena.org.uk>
Hi Mark
On 09/10/2019 18:52, Mark Brown wrote:
> On Tue, Sep 24, 2019 at 10:13:18AM +0100, Suzuki K Poulose wrote:
>> On 16/08/2019 13:10, Mark Brown wrote:
>
>>> We definitely need some variable I think, and I think you're right that
>>> making the decision on the boot CPU would simplify things a lot. The
>
>> relocating the kernel. So, we may be able to perform "raw cpuid check" on
>> the boot CPU with MMU turned on, before we re-write the pagetables for KASLR
>> displacement and nG if that is needed (by maybe updating SWWAPPER_MMU_FLAGS) for
>> the boot CPU and store this information somewhere. Thus we may be able to
>> avoid another re-write of the pagetables after we have booted the secondaries.
>
> The boot CPU is straightforward, there is only an issue on the
> secondaries where IIRC the rewrite code needs some updates as we
> get left with non-global mappings lying around.
>
>> Discussing this with Catalin, he suggests to use a variable for the status
>> of "nG" flag for PTE/PMD_MAYBE_NG, to avoid calling the helper function
>> all the time. By using the per-CPU check we can make sure the flag is uptodate.
>
> That was the discussion about the variable above. We need one
> for non-optimization reasons anyway since we can't rely on
> checking the state on the current CPU.
>
>> Also, we can continue to fail the hotplugged CPUs if we detect that the
>> pagetables are Global and the new CPU requires nG (for heterogeneous
>> systems).
>
> There's no continuing to reject those CPUs unfortunately, we
> don't reject anything currently. Any such systems would
In fact we do reject the hotplugged CPUs, after we have finalised
the capabilities for KPTI. So, I don't see how the behavior is different.
Cheers
Suzuki
> experience a regression when moving to a kernel where E0PD is
> enabled which doesn't seem ideal.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists•infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-10-10 10:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-14 18:31 [PATCH v2 0/2] arm64: E0PD support Mark Brown
2019-08-14 18:31 ` [PATCH v2 1/2] arm64: Add initial support for E0PD Mark Brown
2019-10-10 16:13 ` Mark Rutland
2019-10-11 11:17 ` Mark Brown
2019-10-11 11:40 ` Will Deacon
2019-10-11 12:57 ` Mark Rutland
2019-10-11 12:58 ` Catalin Marinas
2019-10-11 13:46 ` Mark Brown
2019-08-14 18:31 ` [PATCH v2 2/2] arm64: Don't use KPTI where we have E0PD Mark Brown
2019-08-15 16:35 ` Will Deacon
2019-08-15 18:00 ` Mark Brown
2019-08-16 11:31 ` Mark Brown
2019-08-16 10:24 ` Catalin Marinas
2019-08-16 12:10 ` Mark Brown
2019-09-24 9:13 ` Suzuki K Poulose
2019-10-09 17:52 ` Mark Brown
2019-10-10 10:24 ` Suzuki K Poulose [this message]
2019-10-10 16:04 ` Mark Brown
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=2d53ed87-34f3-33e1-5501-77895662c47a@arm.com \
--to=suzuki.poulose@arm$(echo .)com \
--cc=broonie@kernel$(echo .)org \
--cc=catalin.marinas@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=will@kernel$(echo .)org \
/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