public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Kevin Hilman <khilman@baylibre.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Sasha Levin <sashal@kernel.org>
Subject: [PATCH AUTOSEL 4.19 21/27] arm64: cpufeature: Don't treat granule sizes as strict
Date: Tue, 20 Aug 2019 09:42:07 -0400	[thread overview]
Message-ID: <20190820134213.11279-21-sashal@kernel.org> (raw)
In-Reply-To: <20190820134213.11279-1-sashal@kernel.org>

From: Will Deacon <will@kernel.org>

[ Upstream commit 5717fe5ab38f9ccb32718bcb03bea68409c9cce4 ]

If a CPU doesn't support the page size for which the kernel is
configured, then we will complain and refuse to bring it online. For
secondary CPUs (and the boot CPU on a system booting with EFI), we will
also print an error identifying the mismatch.

Consequently, the only time that the cpufeature code can detect a
granule size mismatch is for a granule other than the one that is
currently being used. Although we would rather such systems didn't
exist, we've unfortunately lost that battle and Kevin reports that
on his amlogic S922X (odroid-n2 board) we end up warning and taining
with defconfig because 16k pages are not supported by all of the CPUs.

In such a situation, we don't actually care about the feature mismatch,
particularly now that KVM only exposes the sanitised view of the CPU
registers (commit 93390c0a1b20 - "arm64: KVM: Hide unsupported AArch64
CPU features from guests"). Treat the granule fields as non-strict and
let Kevin run without a tainted kernel.

Cc: Marc Zyngier <maz@kernel.org>
Reported-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
[catalin.marinas@arm.com: changelog updated with KVM sanitised regs commit]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/arm64/kernel/cpufeature.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index bce06083685dc..94babc3d0ec2c 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -165,9 +165,17 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
 };
 
 static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
-	S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI),
-	S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI),
-	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI),
+	/*
+	 * We already refuse to boot CPUs that don't support our configured
+	 * page size, so we can only detect mismatches for a page size other
+	 * than the one we're currently using. Unfortunately, SoCs like this
+	 * exist in the wild so, even though we don't like it, we'll have to go
+	 * along with it and treat them as non-strict.
+	 */
+	S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI),
+	S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI),
+	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI),
+
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_BIGENDEL0_SHIFT, 4, 0),
 	/* Linux shouldn't care about secure memory */
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_SNSMEM_SHIFT, 4, 0),
-- 
2.20.1


  parent reply	other threads:[~2019-08-20 13:45 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-20 13:41 [PATCH AUTOSEL 4.19 01/27] dmaengine: ste_dma40: fix unneeded variable warning Sasha Levin
2019-08-20 13:41 ` [PATCH AUTOSEL 4.19 02/27] nvme-multipath: revalidate nvme_ns_head gendisk in nvme_validate_ns Sasha Levin
2019-08-20 13:41 ` [PATCH AUTOSEL 4.19 03/27] afs: Fix the CB.ProbeUuid service handler to reply correctly Sasha Levin
2019-08-20 13:41 ` [PATCH AUTOSEL 4.19 04/27] afs: Fix loop index mixup in afs_deliver_vl_get_entry_by_name_u() Sasha Levin
2019-08-20 13:41 ` [PATCH AUTOSEL 4.19 05/27] fs: afs: Fix a possible null-pointer dereference in afs_put_read() Sasha Levin
2019-08-20 13:41 ` [PATCH AUTOSEL 4.19 06/27] afs: Only update d_fsdata if different in afs_d_revalidate() Sasha Levin
2019-08-20 13:41 ` [PATCH AUTOSEL 4.19 07/27] intel_th: Use the correct style for SPDX License Identifier Sasha Levin
2019-08-20 13:47   ` Joe Perches
2019-08-20 19:37     ` Sasha Levin
2019-08-20 13:41 ` [PATCH AUTOSEL 4.19 08/27] nvmet-loop: Flush nvme_delete_wq when removing the port Sasha Levin
2019-08-20 13:41 ` [PATCH AUTOSEL 4.19 09/27] nvme: fix a possible deadlock when passthru commands sent to a multipath device Sasha Levin
2019-08-20 13:41 ` [PATCH AUTOSEL 4.19 10/27] nvme-pci: Fix async probe remove race Sasha Levin
2019-08-20 13:41 ` [PATCH AUTOSEL 4.19 11/27] soundwire: cadence_master: fix register definition for SLAVE_STATE Sasha Levin
2019-08-20 13:41 ` [PATCH AUTOSEL 4.19 12/27] soundwire: cadence_master: fix definitions for INTSTAT0/1 Sasha Levin
2019-08-20 13:41 ` [PATCH AUTOSEL 4.19 13/27] iio: adc: max9611: Fix temperature reading in probe Sasha Levin
2019-08-20 13:42 ` [PATCH AUTOSEL 4.19 14/27] auxdisplay: panel: need to delete scan_timer when misc_register fails in panel_attach Sasha Levin
2019-08-20 13:42 ` [PATCH AUTOSEL 4.19 15/27] dmaengine: stm32-mdma: Fix a possible null-pointer dereference in stm32_mdma_irq_handler() Sasha Levin
2019-08-20 13:42 ` [PATCH AUTOSEL 4.19 16/27] omap-dma/omap_vout_vrfb: fix off-by-one fi value Sasha Levin
2019-08-20 13:42 ` [PATCH AUTOSEL 4.19 17/27] iommu/dma: Handle SG length overflow better Sasha Levin
2019-08-20 13:42 ` [PATCH AUTOSEL 4.19 18/27] usb: gadget: composite: Clear "suspended" on reset/disconnect Sasha Levin
2019-08-20 13:42 ` [PATCH AUTOSEL 4.19 19/27] usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt Sasha Levin
2019-08-20 13:42 ` [PATCH AUTOSEL 4.19 20/27] xen/blkback: fix memory leaks Sasha Levin
2019-08-20 13:42 ` Sasha Levin [this message]
2019-08-20 13:42 ` [PATCH AUTOSEL 4.19 22/27] i2c: rcar: avoid race when unregistering slave client Sasha Levin
2019-08-20 13:42 ` [PATCH AUTOSEL 4.19 23/27] i2c: emev2: " Sasha Levin
2019-08-20 13:42 ` [PATCH AUTOSEL 4.19 24/27] drm/ast: Fixed reboot test may cause system hanged Sasha Levin
2019-08-20 13:42 ` [PATCH AUTOSEL 4.19 25/27] usb: host: fotg2: restart hcd after port reset Sasha Levin
2019-08-20 13:42 ` [PATCH AUTOSEL 4.19 26/27] tools: hv: fixed Python pep8/flake8 warnings for lsvmbus Sasha Levin
2019-08-20 13:42 ` [PATCH AUTOSEL 4.19 27/27] tools: hv: fix KVP and VSS daemons exit code Sasha Levin

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=20190820134213.11279-21-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=khilman@baylibre.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=suzuki.poulose@arm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox