All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: "Liao, Chang" <liaochang1@huawei.com>
Cc: kristina.martsenko@arm.com, will@kernel.org,
	mark.rutland@arm.com, sashal@kernel.org,
	yangjiangshui@h-partners.com, zouyipeng@huawei.com,
	justin.he@arm.com, zengheng4@huawei.com,
	yangyicong@hisilicon.com, ruanjinjie <ruanjinjie@huawei.com>,
	inux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] SCTLR_EL1.TIDCP toggling for performance
Date: Fri, 18 Jul 2025 20:03:53 +0100	[thread overview]
Message-ID: <aHqamaqueuk18NyS@arm.com> (raw)
In-Reply-To: <24afb8de-622a-4865-bd8e-8e89ccfff8f4@huawei.com>

On Fri, Jul 18, 2025 at 10:32:00AM +0800, Liao, Chang wrote:
> I've reviewed your patch [1] for FEAT_TIDCP1 support, which by default traps EL0
> accesses to implementation-defined system registers and instructions at EL1/EL2.
> 
> Do you have any plans to add support for toggling the SCTLR_EL1.TIDCP1 bit? I'm
> encountering performance degradation on CPU where certain implementation-defined
> registers and instructions are designed for EL0 performance use. The trapping
> overhead is substantial enough to compromise any benefits, and it's even worse
> in virtualization. Therefore, I'm hoping there's a way to clear the SCTLR_EL1.TIDCP1
> bit on such platforms, perhaps via a kernel config option or command-line parameter.
> Alternatively, do you have a better solution for gracefully toggling this bit on
> and off?

Given that we don't know what imp def functionality is available, what
side-effects it has, we should not allow user-space to toggle such bit,
nor allow the user access to those registers.

System-wide, passing id_aa64mmfr1.tidcp1=0 on the kernel command line
may work.

-- 
Catalin

  parent reply	other threads:[~2025-07-18 19:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-18  2:32 [RFC] SCTLR_EL1.TIDCP toggling for performance Liao, Chang
2025-07-18 17:28 ` Kristina Martšenko
2025-07-22  1:47   ` Liao, Chang
2025-07-18 19:03 ` Catalin Marinas [this message]
2025-07-22  1:47   ` Liao, Chang

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=aHqamaqueuk18NyS@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=inux-arm-kernel@lists.infradead.org \
    --cc=justin.he@arm.com \
    --cc=kristina.martsenko@arm.com \
    --cc=liaochang1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=ruanjinjie@huawei.com \
    --cc=sashal@kernel.org \
    --cc=will@kernel.org \
    --cc=yangjiangshui@h-partners.com \
    --cc=yangyicong@hisilicon.com \
    --cc=zengheng4@huawei.com \
    --cc=zouyipeng@huawei.com \
    /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.