All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Zhou Wang" <wangzhou1@hisilicon.com>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>, "Marc Zyngier" <maz@kernel.org>,
	"Oliver Upton" <oliver.upton@linux.dev>,
	"Joey Gouly" <joey.gouly@arm.com>,
	"Suzuki K Poulose" <suzuki.poulose@arm.com>,
	"Zenghui Yu" <yuzenghui@huawei.com>
Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	yangyccccc@gmail.com, prime.zeng@hisilicon.com,
	xuwei5@huawei.com
Subject: Re: [PATCH v6 7/7] kselftest/arm64: Add HWCAP test for FEAT_{LS64, LS64_V}
Date: Fri, 24 Oct 2025 18:18:18 +0200	[thread overview]
Message-ID: <e40ce220-e857-4ecf-985b-40407f99fcb3@app.fastmail.com> (raw)
In-Reply-To: <20251024090819.4097819-8-wangzhou1@hisilicon.com>

On Fri, Oct 24, 2025, at 11:08, Zhou Wang wrote:

> +static void ls64_sigill(void)
> +{
> +	struct sigaction ign, old;
> +	char src[64] __aligned(64) = { 1 };
> +
> +	/*
> +	 * LS64, LS64_V require target memory to be Device/Non-cacheable (if
> +	 * FEAT_LS64WB not supported) and the completer supports these
> +	 * instructions, otherwise we'll receive a SIGBUS. Since we are only
> +	 * testing the ABI here, so just ignore the SIGBUS and see if we can
> +	 * execute the instructions without receiving a SIGILL. Restore the
> +	 * handler of SIGBUS after this test.
> +	 */
> +	ign.sa_sigaction = ignore_signal;
> +	ign.sa_flags = SA_SIGINFO | SA_RESTART;
> +	sigemptyset(&ign.sa_mask);
> +	sigaction(SIGBUS, &ign, &old);
> +
> +	register void *xn asm ("x8") = src;
> +	register u64 xt_1 asm ("x0");
> +	register u64 __maybe_unused xt_2 asm ("x1");
> +	register u64 __maybe_unused xt_3 asm ("x2");
> +	register u64 __maybe_unused xt_4 asm ("x3");
> +	register u64 __maybe_unused xt_5 asm ("x4");
> +	register u64 __maybe_unused xt_6 asm ("x5");
> +	register u64 __maybe_unused xt_7 asm ("x6");
> +	register u64 __maybe_unused xt_8 asm ("x7");
> +
> +	/* LD64B x0, [x8] */
> +	asm volatile(".inst 0xf83fd100" : "=r" (xt_1) : "r" (xn));

Relying on the __maybe_unused register declaration seems a little
fragile, can you change this so that the inline asm specifies
all of the registers correctly as input/output arguments?

> +static void ls64_v_sigill(void)
> +{
> +	struct sigaction ign, old;
> +	char dst[64] __aligned(64);
> +
> +	/* See comment in ls64_sigill() */
> +	ign.sa_sigaction = ignore_signal;
> +	ign.sa_flags = SA_SIGINFO | SA_RESTART;
> +	sigemptyset(&ign.sa_mask);
> +	sigaction(SIGBUS, &ign, &old);
> +
> +	register void *xn asm ("x8") = dst;
> +	register u64 xt_1 asm ("x0") = 1;
> +	register u64 __maybe_unused xt_2 asm ("x1") = 2;
> +	register u64 __maybe_unused xt_3 asm ("x2") = 3;
> +	register u64 __maybe_unused xt_4 asm ("x3") = 4;
> +	register u64 __maybe_unused xt_5 asm ("x4") = 5;
> +	register u64 __maybe_unused xt_6 asm ("x5") = 6;
> +	register u64 __maybe_unused xt_7 asm ("x6") = 7;
> +	register u64 __maybe_unused xt_8 asm ("x7") = 8;
> +	register u64 st   asm ("x9");
> +
> +	/* ST64BV x9, x0, [x8] */
> +	asm volatile(".inst 0xf829b100" : "=r" (st) : "r" (xt_1), "r" (xn));
> +
> +	sigaction(SIGBUS, &old, NULL);

Is ST64BV expected to cause SIGBUS here, or should it return the
0xffffffffffffffff output to indicate an unsupported memory area?

     Arnd

  reply	other threads:[~2025-10-24 16:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-24  9:08 [PATCH v6 0/7] Add support for FEAT_{LS64, LS64_V} and related tests Zhou Wang
2025-10-24  9:08 ` [PATCH v6 1/7] KVM: arm64: Add exit to userspace on {LD,ST}64B* outside of memslots Zhou Wang
2025-10-24  9:08 ` [PATCH v6 2/7] KVM: arm64: Add documentation for KVM_EXIT_ARM_LDST64B Zhou Wang
2025-10-24  9:08 ` [PATCH v6 3/7] KVM: arm64: Handle DABT caused by LS64* instructions on unsupported memory Zhou Wang
2025-10-24 19:54   ` Oliver Upton
2025-10-25 10:11     ` Zhou Wang
2025-10-24  9:08 ` [PATCH v6 4/7] arm64: Provide basic EL2 setup for FEAT_{LS64, LS64_V} usage at EL0/1 Zhou Wang
2025-10-24  9:08 ` [PATCH v6 5/7] arm64: Add support for FEAT_{LS64, LS64_V} Zhou Wang
2025-10-24  9:08 ` [PATCH v6 6/7] KVM: arm64: Enable FEAT_{LS64, LS64_V} in the supported guest Zhou Wang
2025-10-24  9:08 ` [PATCH v6 7/7] kselftest/arm64: Add HWCAP test for FEAT_{LS64, LS64_V} Zhou Wang
2025-10-24 16:18   ` Arnd Bergmann [this message]
2025-10-25 10:06     ` Zhou Wang
2025-10-26 21:56       ` Arnd Bergmann
2025-10-27  2:50       ` Zhou Wang
2025-10-27  6:57         ` Arnd Bergmann
2025-10-24 16:22 ` [PATCH v6 0/7] Add support for FEAT_{LS64, LS64_V} and related tests Arnd Bergmann
2025-10-25  8:42   ` Zhou Wang
2025-10-26 21:59     ` Arnd Bergmann

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=e40ce220-e857-4ecf-985b-40407f99fcb3@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=prime.zeng@hisilicon.com \
    --cc=suzuki.poulose@arm.com \
    --cc=wangzhou1@hisilicon.com \
    --cc=will@kernel.org \
    --cc=xuwei5@huawei.com \
    --cc=yangyccccc@gmail.com \
    --cc=yuzenghui@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.