public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm•com>
To: linux-arm-kernel@lists•infradead.org, kvmarm@lists•linux.dev
Cc: broonie@kernel•org, catalin.marinas@arm•com, james.morse@arm•com,
	maz@kernel•org, oupton@kernel•org, tabba@google•com,
	vladimir.murzin@arm•com, will@kernel•org
Subject: Re: [PATCH v3 02/18] KVM: arm64: Don't override FFR save/restore argument
Date: Wed, 3 Jun 2026 10:25:23 +0100	[thread overview]
Message-ID: <ah_zAzgSBzQsZOOU@J2N7QTR9R3> (raw)
In-Reply-To: <20260602151150.925126-3-mark.rutland@arm.com>

On Tue, Jun 02, 2026 at 04:11:34PM +0100, Mark Rutland wrote:
>  SYM_FUNC_START(__sve_restore_state)
> -	mov	x2, #1
>  	sve_load 0, x1, x2, 3
>  	ret
>  SYM_FUNC_END(__sve_restore_state)
>  
>  SYM_FUNC_START(__sve_save_state)
> -	mov	x2, #1
>  	sve_save 0, x1, x2, 3
>  	ret
>  SYM_FUNC_END(__sve_save_state)

Sashiko pointed out that this change opens a type mismatch bug. Details
below; I'll send a v4 which fixes this since it's also a latent issue
elsewhere.

The function prototypes take the FFR parameter as a 32-bit int:

  void __sve_restore_state(void *sve_pffr, u32 *fpsr, int restore_ffr)
  void __sve_save_state(void *sve_pffr, u32 *fpsr, int save_ffr)

Per the AAPCS64 parameter passing rules, the callee is responsible for
widening values, and where a register contains a 32-bit argument, the
upper 32 bits of the register are permitted to contain arbitrary values.

The CBZ instructions in the sve_save and sve_load macros will consume
all 64 bits of x2, so depending on how the compiler generated the
'restore_ffr' or 'save_ffr' argument (and if the upper 32 bits happen to
be non-zero), it's possible that we'll attempt to save/restore FFR when
we shouldn't. In practice it's most likely the compiler will zero the
entire register when passing false, but the compiler isn't required to
do so.

The same issue exists in the sve_{save,load}_state() and
sme_{save,load}_state() functions before this series, and hence we
should fix that as a preparatory step for the sake of stable kernels.

We happened to avoid that issue in sve_flush_live() by virtue of passing
bool (which the caller has to pass as 0 or 1 specifically) and using tbz
on bit 0.

Mark.


  parent reply	other threads:[~2026-06-03  9:25 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-02 15:11 [PATCH v3 00/18] arm64+KVM: FPSIMD/SVE/SME cleanups Mark Rutland
2026-06-02 15:11 ` [PATCH v3 01/18] KVM: arm64: Don't include <asm/fpsimdmacros.h> Mark Rutland
2026-06-02 15:11 ` [PATCH v3 02/18] KVM: arm64: Don't override FFR save/restore argument Mark Rutland
2026-06-02 15:36   ` Mark Brown
2026-06-03  9:25   ` Mark Rutland [this message]
2026-06-02 15:11 ` [PATCH v3 03/18] KVM: arm64: pkvm: Save host FPMR in host cpu context Mark Rutland
2026-06-02 15:11 ` [PATCH v3 04/18] KVM: arm64: pkvm: Remove struct cpu_sve_state Mark Rutland
2026-06-02 15:11 ` [PATCH v3 05/18] arm64: fpsimd: Fold sve_init_regs() into do_sve_acc() Mark Rutland
2026-06-02 15:11 ` [PATCH v3 06/18] arm64: fpsimd: Remove sve_set_vq() and sme_set_vq() Mark Rutland
2026-06-02 15:11 ` [PATCH v3 07/18] arm64: fpsimd: Use assembler for SVE instructions Mark Rutland
2026-06-02 15:11 ` [PATCH v3 08/18] arm64: fpsimd: Use assembler for baseline SME instructions Mark Rutland
2026-06-02 15:11 ` [PATCH v3 09/18] arm64: fpsimd: Move sve_get_vl() and sme_get_vl() inline Mark Rutland
2026-06-02 15:11 ` [PATCH v3 10/18] arm64: sysreg: Add FPCR and FPSR Mark Rutland
2026-06-02 15:11 ` [PATCH v3 11/18] arm64: fpsimd: Split FPSR/FPCR from SVE save/restore Mark Rutland
2026-06-02 15:11 ` [PATCH v3 12/18] arm64: fpsimd: Move fpsimd save/restore inline Mark Rutland
2026-06-02 15:11 ` [PATCH v3 13/18] arm64: fpsimd: Use opaque type for SVE state Mark Rutland
2026-06-02 15:11 ` [PATCH v3 14/18] arm64: fpsimd: Use opaque type for SME state Mark Rutland
2026-06-02 15:11 ` [PATCH v3 15/18] arm64: fpsimd: Move SVE save/restore inline Mark Rutland
2026-06-02 15:11 ` [PATCH v3 16/18] arm64: fpsimd: Move sve_flush_live() inline Mark Rutland
2026-06-02 15:11 ` [PATCH v3 17/18] arm64: fpsimd: Move SME save/restore inline Mark Rutland
2026-06-02 15:30   ` Mark Brown
2026-06-02 15:11 ` [PATCH v3 18/18] arm64: fpsimd: Remove <asm/fpsimdmacros.h> Mark Rutland
2026-06-02 15:33   ` Mark Brown

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=ah_zAzgSBzQsZOOU@J2N7QTR9R3 \
    --to=mark.rutland@arm$(echo .)com \
    --cc=broonie@kernel$(echo .)org \
    --cc=catalin.marinas@arm$(echo .)com \
    --cc=james.morse@arm$(echo .)com \
    --cc=kvmarm@lists$(echo .)linux.dev \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    --cc=maz@kernel$(echo .)org \
    --cc=oupton@kernel$(echo .)org \
    --cc=tabba@google$(echo .)com \
    --cc=vladimir.murzin@arm$(echo .)com \
    --cc=will@kernel$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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