All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Yicong Yang <yangyicong@huawei.com>,
	will@kernel.org, mark.rutland@arm.com, broonie@kernel.org,
	linux-arm-kernel@lists.infradead.org, oliver.upton@linux.dev,
	ryan.roberts@arm.com, linuxarm@huawei.com,
	jonathan.cameron@huawei.com,
	shameerali.kolothum.thodi@huawei.com, prime.zeng@hisilicon.com,
	xuwei5@huawei.com, wangkefeng.wang@huawei.com,
	yangyicong@hisilicon.com
Subject: Re: [PATCH v4 3/5] arm64: Add support for FEAT_HAFT
Date: Tue, 05 Nov 2024 11:52:51 +0000	[thread overview]
Message-ID: <86fro528z0.wl-maz@kernel.org> (raw)
In-Reply-To: <ZynsQl6vpA8tOHY8@arm.com>

On Tue, 05 Nov 2024 09:58:26 +0000,
Catalin Marinas <catalin.marinas@arm.com> wrote:
> 
> On Tue, Nov 05, 2024 at 08:35:51AM +0000, Marc Zyngier wrote:
> > On Mon, 04 Nov 2024 17:28:48 +0000,
> > Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > On Sat, Nov 02, 2024 at 06:42:33PM +0800, Yicong Yang wrote:
> > > > diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> > > > index ccbae4525891..0bc88df7cb35 100644
> > > > --- a/arch/arm64/mm/proc.S
> > > > +++ b/arch/arm64/mm/proc.S
> > > > @@ -498,6 +498,10 @@ alternative_else_nop_endif
> > > >  	and	x9, x9, ID_AA64MMFR1_EL1_HAFDBS_MASK
> > > >  	cbz	x9, 1f
> > > >  	orr	tcr, tcr, #TCR_HA		// hardware Access flag update
> > > > +
> > > > +#ifdef CONFIG_ARM64_HAFT
> > > > +	orr	tcr2, tcr2, TCR2_EL1x_HAFT
> > > > +#endif /* CONFIG_ARM64_HAFT */
> > > >  1:
> > > >  #endif	/* CONFIG_ARM64_HW_AFDBM */
> > > >  	msr	mair_el1, mair
> > > 
> > > If you still want #ifdefs, I'd have left it outside the HW_AFDBM. We
> > > already have a dependency in the Kconfig. Anyway, I can fix this up.
> > > 
> > > I think as an additional patch we can also remove the ID checks for the
> > > tcr bit in tge HW_AFDBM case. But that's unrelated to this series.
> > 
> > I think you want to be careful with this one. I know of at least one
> > implementation that has a broken FEAT_HAFDBS implementation, that
> > removes it from the ID registers, but where the control bit in TCR_ELx
> > still takes effect.
> > 
> > Please see 6df696cd9bc1 ("arm64: errata: Mitigate Ampere1 erratum
> > AC03_CPU_38 at stage-2") which indicates how we actually rely on the
> > check for S1 translation.
> 
> Ah, thanks for this. So the hardware with the erratum above can still
> update the pte after it has been marked invalid, hence we can't turn it
> on in TCR_EL1 even if the rest of the kernel considers the feature
> disabled. So yes, the HAFDBS code needs to stay as is.

Indeed. Atomicity is overrated, let's go shopping.

> Let's hope the hardware people learnt and we won't have similar errata
> for FEAT_HAFT.

If I was religious, I'd light a candle. But we've both seen enough HW
to know that they *will* fsck it up. We just don't know how yet.

	M.

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


  reply	other threads:[~2024-11-05 11:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-02 10:42 [PATCH v4 0/5] Support Armv8.9/v9.4 FEAT_HAFT Yicong Yang
2024-11-02 10:42 ` [PATCH v4 1/5] arm64/sysreg: Update ID_AA64MMFR1_EL1 register Yicong Yang
2024-11-02 10:42 ` [PATCH v4 2/5] arm64: setup: name 'tcr2' register Yicong Yang
2024-11-02 10:42 ` [PATCH v4 3/5] arm64: Add support for FEAT_HAFT Yicong Yang
2024-11-04 17:28   ` Catalin Marinas
2024-11-05  2:47     ` Yicong Yang
2024-11-05 10:38       ` Yicong Yang
2024-11-05 10:54         ` Catalin Marinas
2024-11-05  8:35     ` Marc Zyngier
2024-11-05  9:58       ` Catalin Marinas
2024-11-05 11:52         ` Marc Zyngier [this message]
2024-11-02 10:42 ` [PATCH v4 4/5] arm64: Enable ARCH_HAS_NONLEAF_PMD_YOUNG Yicong Yang
2024-11-04 17:29   ` Catalin Marinas
2024-11-02 10:42 ` [PATCH v4 5/5] arm64: pgtable: Warn unexpected pmdp_test_and_clear_young() Yicong Yang
2024-11-04 17:29   ` Catalin Marinas
2024-11-05 13:51 ` [PATCH v4 0/5] Support Armv8.9/v9.4 FEAT_HAFT Catalin Marinas

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=86fro528z0.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linuxarm@huawei.com \
    --cc=mark.rutland@arm.com \
    --cc=oliver.upton@linux.dev \
    --cc=prime.zeng@hisilicon.com \
    --cc=ryan.roberts@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=will@kernel.org \
    --cc=xuwei5@huawei.com \
    --cc=yangyicong@hisilicon.com \
    --cc=yangyicong@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.