From: Marc Zyngier <maz@kernel.org>
To: "Jonathan Neuschäfer" <j.ne@posteo.net>
Cc: linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
Prasad Sodagudi <psodagud@codeaurora.org>,
Srinivas Ramana <sramana@codeaurora.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Hector Martin <marcan@marcan.st>,
Ajay Patil <pajay@qti.qualcomm.com>,
kernel-team@android.com, Will Deacon <will@kernel.org>,
Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH v7 23/23] [DO NOT MERGE] arm64: Cope with CPUs stuck in VHE mode
Date: Mon, 22 Feb 2021 09:47:06 +0000 [thread overview]
Message-ID: <4d4e9a5cff65dbd8861f829089f570e5@kernel.org> (raw)
In-Reply-To: <YDN6BtDhzmF5OtBO@latitude>
Hi Jonathan,
On 2021-02-22 09:35, Jonathan Neuschäfer wrote:
> Hi,
>
> On Mon, Feb 08, 2021 at 09:57:32AM +0000, Marc Zyngier wrote:
>> It seems that the CPU known as Apple M1 has the terrible habit
>> of being stuck with HCR_EL2.E2H==1, in violation of the architecture.
>
> Minor nitpick from the sideline: The M1 SoC has two kinds of CPU in it
> (Icestorm and Firestorm), which makes "CPU known as Apple M1" a bit
> imprecise.
Fair enough. How about something along the lines of:
"At least some of the CPUs integrated in the Apple M1 SoC have
the terrible habit..."
> In practicality it seems unlikely though, that Icestorm and Firestorm
> act differently with regards to the code in this patch.
This is my hunch as well. And if they did, it shouldn't be a big deal:
the "architecture compliant" CPUs would simply transition via EL1
as expected, and join their buggy friends running at EL2 slightly later.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: "Jonathan Neuschäfer" <j.ne@posteo.net>
Cc: Srinivas Ramana <sramana@codeaurora.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Hector Martin <marcan@marcan.st>,
linux-kernel@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
Will Deacon <will@kernel.org>,
Ajay Patil <pajay@qti.qualcomm.com>,
Prasad Sodagudi <psodagud@codeaurora.org>,
kernel-team@android.com, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 23/23] [DO NOT MERGE] arm64: Cope with CPUs stuck in VHE mode
Date: Mon, 22 Feb 2021 09:47:06 +0000 [thread overview]
Message-ID: <4d4e9a5cff65dbd8861f829089f570e5@kernel.org> (raw)
In-Reply-To: <YDN6BtDhzmF5OtBO@latitude>
Hi Jonathan,
On 2021-02-22 09:35, Jonathan Neuschäfer wrote:
> Hi,
>
> On Mon, Feb 08, 2021 at 09:57:32AM +0000, Marc Zyngier wrote:
>> It seems that the CPU known as Apple M1 has the terrible habit
>> of being stuck with HCR_EL2.E2H==1, in violation of the architecture.
>
> Minor nitpick from the sideline: The M1 SoC has two kinds of CPU in it
> (Icestorm and Firestorm), which makes "CPU known as Apple M1" a bit
> imprecise.
Fair enough. How about something along the lines of:
"At least some of the CPUs integrated in the Apple M1 SoC have
the terrible habit..."
> In practicality it seems unlikely though, that Icestorm and Firestorm
> act differently with regards to the code in this patch.
This is my hunch as well. And if they did, it shouldn't be a big deal:
the "architecture compliant" CPUs would simply transition via EL1
as expected, and join their buggy friends running at EL2 slightly later.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: "Jonathan Neuschäfer" <j.ne@posteo.net>
Cc: Srinivas Ramana <sramana@codeaurora.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Hector Martin <marcan@marcan.st>,
linux-kernel@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
Will Deacon <will@kernel.org>,
Ajay Patil <pajay@qti.qualcomm.com>,
Prasad Sodagudi <psodagud@codeaurora.org>,
kernel-team@android.com, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 23/23] [DO NOT MERGE] arm64: Cope with CPUs stuck in VHE mode
Date: Mon, 22 Feb 2021 09:47:06 +0000 [thread overview]
Message-ID: <4d4e9a5cff65dbd8861f829089f570e5@kernel.org> (raw)
In-Reply-To: <YDN6BtDhzmF5OtBO@latitude>
Hi Jonathan,
On 2021-02-22 09:35, Jonathan Neuschäfer wrote:
> Hi,
>
> On Mon, Feb 08, 2021 at 09:57:32AM +0000, Marc Zyngier wrote:
>> It seems that the CPU known as Apple M1 has the terrible habit
>> of being stuck with HCR_EL2.E2H==1, in violation of the architecture.
>
> Minor nitpick from the sideline: The M1 SoC has two kinds of CPU in it
> (Icestorm and Firestorm), which makes "CPU known as Apple M1" a bit
> imprecise.
Fair enough. How about something along the lines of:
"At least some of the CPUs integrated in the Apple M1 SoC have
the terrible habit..."
> In practicality it seems unlikely though, that Icestorm and Firestorm
> act differently with regards to the code in this patch.
This is my hunch as well. And if they did, it shouldn't be a big deal:
the "architecture compliant" CPUs would simply transition via EL1
as expected, and join their buggy friends running at EL2 slightly later.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
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:[~2021-02-22 9:48 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-08 9:57 [PATCH v7 00/23] arm64: Early CPU feature override, and applications to VHE, BTI and PAuth Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 01/23] arm64: Fix labels in el2_setup macros Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 02/23] arm64: Fix outdated TCR setup comment Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 03/23] arm64: Turn the MMU-on sequence into a macro Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 04/23] arm64: Provide an 'upgrade to VHE' stub hypercall Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 05/23] arm64: Initialise as nVHE before switching to VHE Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 06/23] arm64: Drop early setting of MDSCR_EL2.TPMS Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 07/23] arm64: Move VHE-specific SPE setup to mutate_to_vhe() Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 08/23] arm64: Simplify init_el2_state to be non-VHE only Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 09/23] arm64: Move SCTLR_EL1 initialisation to EL-agnostic code Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 10/23] arm64: cpufeature: Add global feature override facility Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 11/23] arm64: cpufeature: Use IDreg override in __read_sysreg_by_encoding() Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 12/23] arm64: Extract early FDT mapping from kaslr_early_init() Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 13/23] arm64: cpufeature: Add an early command-line cpufeature override facility Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 14/23] arm64: Allow ID_AA64MMFR1_EL1.VH to be overridden from the command line Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 15/23] arm64: Honor VHE being disabled from the command-line Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 16/23] arm64: Add an aliasing facility for the idreg override Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 17/23] arm64: Make kvm-arm.mode={nvhe, protected} an alias of id_aa64mmfr1.vh=0 Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 18/23] KVM: arm64: Document HVC_VHE_RESTART stub hypercall Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 19/23] arm64: Move "nokaslr" over to the early cpufeature infrastructure Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 20/23] arm64: cpufeatures: Allow disabling of BTI from the command-line Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 21/23] arm64: Defer enabling pointer authentication on boot core Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 22/23] arm64: cpufeatures: Allow disabling of Pointer Auth from the command-line Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 23/23] [DO NOT MERGE] arm64: Cope with CPUs stuck in VHE mode Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-22 9:35 ` Jonathan Neuschäfer
2021-02-22 9:35 ` Jonathan Neuschäfer
2021-02-22 9:35 ` Jonathan Neuschäfer
2021-02-22 9:47 ` Marc Zyngier [this message]
2021-02-22 9:47 ` Marc Zyngier
2021-02-22 9:47 ` Marc Zyngier
2021-02-08 14:32 ` [PATCH v7 00/23] arm64: Early CPU feature override, and applications to VHE, BTI and PAuth Will Deacon
2021-02-08 14:32 ` Will Deacon
2021-02-08 14:32 ` Will Deacon
2021-02-08 14:40 ` Ard Biesheuvel
2021-02-08 14:40 ` Ard Biesheuvel
2021-02-08 14:40 ` Ard Biesheuvel
2021-02-08 15:02 ` Marc Zyngier
2021-02-08 15:02 ` Marc Zyngier
2021-02-08 15:02 ` Marc Zyngier
2021-02-08 16:30 ` Marc Zyngier
2021-02-08 16:30 ` Marc Zyngier
2021-02-08 16:30 ` Marc Zyngier
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=4d4e9a5cff65dbd8861f829089f570e5@kernel.org \
--to=maz@kernel.org \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=j.ne@posteo.net \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=pajay@qti.qualcomm.com \
--cc=psodagud@codeaurora.org \
--cc=sramana@codeaurora.org \
--cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.