Linux KVM/arm64 development list
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox