Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Zenghui Yu <yuzenghui@huawei.com>
To: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Shuah Khan <shuah@kernel.org>,
	Alan Hayward <alan.hayward@arm.com>,
	Luis Machado <luis.machado@arm.com>,
	Szabolcs Nagy <szabolcs.nagy@arm.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH v3 14/21] kselftest/arm64: Add a stress test program for ZT0
Date: Sat, 17 Dec 2022 17:15:35 +0800	[thread overview]
Message-ID: <bc1c581d-55e4-c867-8cf2-269084756e91@huawei.com> (raw)
In-Reply-To: <20221111215026.813348-15-broonie@kernel.org>

On 2022/11/12 5:50, Mark Brown wrote:
> +// Trivial memory copy: copy x2 bytes, starting at address x1, to address x0.
> +// Clobbers x0-x3
> +function memcpy
> +	cmp	x2, #0
> +	b.eq	1f
> +0:	ldrb	w3, [x1], #1
> +	strb	w3, [x0], #1
> +	subs	x2, x2, #1
> +	b.ne	0b
> +1:	ret
> +endfunction

There is an exact same implementation of memcpy in fp/asm-utils.S.

> +
> +// Generate a test pattern for storage in ZT
> +// x0: pid
> +// x1: generation
> +
> +// These values are used to constuct a 32-bit pattern that is repeated in the

s/constuct/construct/ ?

> +// scratch buffer as many times as will fit:
> +// bits 31:24	generation number (increments once per test_loop)
> +// bits 23: 8	pid
> +// bits  7: 0	32-bit lane index
> +
> +function pattern
> +	mov	w3, wzr
> +	bfi	w3, w0, #8, #16		// PID
> +	bfi	w3, w1, #24, #8		// Generation
> +
> +	ldr	x0, =scratch
> +	mov	w1, #ZT_B / 4
> +
> +0:	str	w3, [x0], #4
> +	add	w3, w3, #1		// Lane
> +	subs	w1, w1, #1
> +	b.ne	0b
> +
> +	ret
> +endfunction
> +
> +// Set up test pattern in a ZT horizontal vector
> +// x0: pid
> +// x1: generation
> +function setup_zt
> +	mov	x4, x30
> +
> +	bl	pattern			// Get pattern in scratch buffer
> +	ldr	x0, =ztref
> +	ldr	x1, =scratch
> +	mov	x2, #ZT_B
> +	bl	memcpy
> +
> +	_ldr_zt 0			// load zt0 from pointer x0

Isn't x0 already clobbered by memcpy (and is now pointing to the
end of ztref)?

> +
> +	ret	x4
> +endfunction
> +
> +// Trivial memory compare: compare x2 bytes starting at address x0 with
> +// bytes starting at address x1.
> +// Returns only if all bytes match; otherwise, the program is aborted.
> +// Clobbers x0-x5.
> +function memcmp
> +	cbz	x2, 2f
> +
> +	stp	x0, x1, [sp, #-0x20]!
> +	str	x2, [sp, #0x10]
> +
> +	mov	x5, #0
> +0:	ldrb	w3, [x0, x5]
> +	ldrb	w4, [x1, x5]
> +	add	x5, x5, #1
> +	cmp	w3, w4
> +	b.ne	1f
> +	subs	x2, x2, #1
> +	b.ne	0b
> +
> +1:	ldr	x2, [sp, #0x10]
> +	ldp	x0, x1, [sp], #0x20
> +	b.ne	barf
> +
> +2:	ret
> +endfunction
> +
> +// Verify that a ZT vector matches its shadow in memory, else abort
> +// Clobbers x0-x7 and x12.

It looks like check_zt doesn't clobber as many registers as "x0-x7
and x12".

> +function check_zt
> +	mov	x3, x30
> +
> +	ldr	x0, =scratch		// Poison scratch
> +	mov	x1, #ZT_B
> +	bl	memfill_ae
> +
> +	ldr	x0, =scratch
> +	_str_zt 0
> +
> +	ldr	x0, =ztref
> +	ldr	x1, =scratch
> +	mov	x2, #ZT_B
> +	mov	x30, x3
> +	b	memcmp
> +endfunction

[...]
> +.Ltest_loop:
> +	mov	x0, x20
> +	mov	x1, x22
> +	bl	setup_zt
> +
> +	mov	x8, #__NR_sched_yield	// Encourage preemption
> +	svc	#0
> +
> +	mov	x0, x20
> +	mov	x1, x22

check_zt receives no parameter so there is no need to initialize
x0 and x1.

> +	bl	check_zt
> +
> +	add	x22, x22, #1	// Everything still working
> +	b	.Ltest_loop
> +
> +.Labort:
> +	mov	x0, #0
> +	mov	x1, #SIGABRT
> +	mov	x8, #__NR_kill
> +	svc	#0
> +endfunction

[...]
> +function svcr_barf

And svcr_barf is unused in zt-test.

Zenghui

  reply	other threads:[~2022-12-17  9:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11 21:50 [PATCH v3 00/21] arm64/sme: Support SME 2 and SME 2.1 Mark Brown
2022-11-11 21:50 ` [PATCH v3 01/21] arm64/sme: Rename za_state to sme_state Mark Brown
2022-11-11 21:50 ` [PATCH v3 02/21] arm64: Document boot requirements for SME 2 Mark Brown
2022-11-11 21:50 ` [PATCH v3 03/21] arm64/sysreg: Update system registers for SME 2 and 2.1 Mark Brown
2022-11-11 21:50 ` [PATCH v3 04/21] arm64/sme: Document SME 2 and SME 2.1 ABI Mark Brown
2022-11-11 21:50 ` [PATCH v3 05/21] arm64/esr: Document ISS for ZT0 being disabled Mark Brown
2022-11-11 21:50 ` [PATCH v3 06/21] arm64/sme: Manually encode ZT0 load and store instructions Mark Brown
2022-12-17  9:40   ` Zenghui Yu
2022-12-19 15:04     ` Mark Brown
2022-11-11 21:50 ` [PATCH v3 07/21] arm64/sme: Enable host kernel to access ZT0 Mark Brown
2022-11-11 21:50 ` [PATCH v3 08/21] arm64/sme: Add basic enumeration for SME2 Mark Brown
2022-11-11 21:50 ` [PATCH v3 09/21] arm64/sme: Provide storage for ZT0 Mark Brown
2022-12-17  9:28   ` Zenghui Yu
2022-11-11 21:50 ` [PATCH v3 10/21] arm64/sme: Implement context switching " Mark Brown
2022-11-11 21:50 ` [PATCH v3 11/21] arm64/sme: Implement signal handling for ZT Mark Brown
2022-11-11 21:50 ` [PATCH v3 12/21] arm64/sme: Implement ZT0 ptrace support Mark Brown
2022-12-17  9:23   ` Zenghui Yu
2022-11-11 21:50 ` [PATCH v3 13/21] arm64/sme: Add hwcaps for SME 2 and 2.1 features Mark Brown
2022-12-19  8:22   ` Zenghui Yu
2022-11-11 21:50 ` [PATCH v3 14/21] kselftest/arm64: Add a stress test program for ZT0 Mark Brown
2022-12-17  9:15   ` Zenghui Yu [this message]
2022-11-11 21:50 ` [PATCH v3 15/21] kselftest/arm64: Cover ZT in the FP stress test Mark Brown
2022-11-11 21:50 ` [PATCH v3 16/21] kselftest/arm64: Enumerate SME2 in the signal test utility code Mark Brown
2022-11-11 21:50 ` [PATCH v3 17/21] kselftest/arm64: Teach the generic signal context validation about ZT Mark Brown
2022-11-11 21:50 ` [PATCH v3 18/21] kselftest/arm64: Add test coverage for ZT register signal frames Mark Brown
2022-11-11 21:50 ` [PATCH v3 19/21] kselftest/arm64: Add SME2 coverage to syscall-abi Mark Brown
2022-11-11 21:50 ` [PATCH v3 20/21] kselftest/arm64: Add coverage of the ZT ptrace regset Mark Brown
2022-11-11 21:50 ` [PATCH v3 21/21] kselftest/arm64: Add coverage of SME 2 and 2.1 hwcaps 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=bc1c581d-55e4-c867-8cf2-269084756e91@huawei.com \
    --to=yuzenghui@huawei.com \
    --cc=alan.hayward@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=luis.machado@arm.com \
    --cc=shuah@kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=szabolcs.nagy@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