All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	Ada Couprie Diaz <ada.coupriediaz@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
	Oliver Upton <oliver.upton@linux.dev>
Subject: Re: [PATCH] arm64: Remove checks for broken Cavium HW from the PI code
Date: Thu, 17 Apr 2025 17:59:45 +0100	[thread overview]
Message-ID: <86o6wuk9ku.wl-maz@kernel.org> (raw)
In-Reply-To: <20250417140147.GA13109@willie-the-truck>

On Thu, 17 Apr 2025 15:01:48 +0100,
Will Deacon <will@kernel.org> wrote:
> 
> Hmm, I'm not really sure about this as it seems to be punishing the poor
> user of the box who really hasn't done anything wrong. The firmware might
> not be passing a KASLR seed to the host, but what about guest VMs? It's
> pretty easy for the VMM to stuff a seed into the DT, so if somebody was
> running VMs on TX1 with kaslr before c8c2647e69bed ("arm64: Make
> _midr_in_range_list() an exported function") and things worked, I don't
> think we should be breaking that so that it crashes in weird ways.

That's a good point, and I should have thought of that.

> Could we just read MIDR_EL1 (read_cpuid_id()) in the PI code to detect
> ThunderX that way? I'm less fussed about the multi-MIDR code working on
> this machine as it's a new feature (and we could disable the new
> hypercalls here if we really cared).

Yeah, probably. Let me have a play with this thing again.

> Alternatively, we could properly rip out the TX1 support and fail to boot
> if we detect it. At least that's deterministic and we could have a useful
> error message about the thing being unsupported.

That'd be the last resort, and I'd rather keep this machine alive as
this is the only v8.0 box I have with 16kB page support.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
	kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: Remove checks for broken Cavium HW from the PI code
Date: Thu, 17 Apr 2025 17:59:45 +0100	[thread overview]
Message-ID: <86o6wuk9ku.wl-maz@kernel.org> (raw)
In-Reply-To: <20250417140147.GA13109@willie-the-truck>

On Thu, 17 Apr 2025 15:01:48 +0100,
Will Deacon <will@kernel.org> wrote:
> 
> Hmm, I'm not really sure about this as it seems to be punishing the poor
> user of the box who really hasn't done anything wrong. The firmware might
> not be passing a KASLR seed to the host, but what about guest VMs? It's
> pretty easy for the VMM to stuff a seed into the DT, so if somebody was
> running VMs on TX1 with kaslr before c8c2647e69bed ("arm64: Make
> _midr_in_range_list() an exported function") and things worked, I don't
> think we should be breaking that so that it crashes in weird ways.

That's a good point, and I should have thought of that.

> Could we just read MIDR_EL1 (read_cpuid_id()) in the PI code to detect
> ThunderX that way? I'm less fussed about the multi-MIDR code working on
> this machine as it's a new feature (and we could disable the new
> hypercalls here if we really cared).

Yeah, probably. Let me have a play with this thing again.

> Alternatively, we could properly rip out the TX1 support and fail to boot
> if we detect it. At least that's deterministic and we could have a useful
> error message about the thing being unsupported.

That'd be the last resort, and I'd rather keep this machine alive as
this is the only v8.0 box I have with 16kB page support.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.


  reply	other threads:[~2025-04-17 16:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-16 12:35 [PATCH] arm64: Remove checks for broken Cavium HW from the PI code Marc Zyngier
2025-04-16 12:35 ` Marc Zyngier
2025-04-16 12:52 ` Catalin Marinas
2025-04-16 12:52   ` Catalin Marinas
2025-04-16 13:05 ` Ada Couprie Diaz
2025-04-17 14:01 ` Will Deacon
2025-04-17 14:01   ` Will Deacon
2025-04-17 16:59   ` Marc Zyngier [this message]
2025-04-17 16:59     ` 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=86o6wuk9ku.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=ada.coupriediaz@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oliver.upton@linux.dev \
    --cc=shameerali.kolothum.thodi@huawei.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 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.