linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Zhou Wang <wangzhou1@hisilicon.com>,
	catalin.marinas@arm.com, will@kernel.org, maz@kernel.org,
	oliver.upton@linux.dev, joey.gouly@arm.com, yuzenghui@huawei.com,
	arnd@arndb.de
Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	yangyccccc@gmail.com, prime.zeng@hisilicon.com,
	xuwei5@huawei.com
Subject: Re: [PATCH v7 1/7] KVM: arm64: Add exit to userspace on {LD,ST}64B* outside of memslots
Date: Fri, 7 Nov 2025 11:48:09 +0000	[thread overview]
Message-ID: <1f0d24ae-c20c-4067-aa0c-b5bbeba367db@arm.com> (raw)
In-Reply-To: <20251107072127.448953-2-wangzhou1@hisilicon.com>

On 07/11/2025 07:21, Zhou Wang wrote:
> From: Marc Zyngier <maz@kernel.org>
> 
> The main use of {LD,ST}64B* is to talk to a device, which is hopefully
> directly assigned to the guest and requires no additional handling.
> 
> However, this does not preclude a VMM from exposing a virtual device
> to the guest, and to allow 64 byte accesses as part of the programming
> interface. A direct consequence of this is that we need to be able
> to forward such access to userspace.
> 
> Given that such a contraption is very unlikely to ever exist, we choose
> to offer a limited service: userspace gets (as part of a new exit reason)
> the ESR, the IPA, and that's it. It is fully expected to handle the full
> semantics of the instructions, deal with ACCDATA, the return values and
> increment PC. Much fun.
> 
> A canonical implementation can also simply inject an abort and be done
> with it. Frankly, don't try to do anything else unless you have time
> to waste.
> 
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>

We also need to document this new EXIT reason here :

Documentation/virt/kvm/api.rst


> ---
>   arch/arm64/kvm/mmio.c    | 27 ++++++++++++++++++++++++++-
>   include/uapi/linux/kvm.h |  3 ++-
>   2 files changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kvm/mmio.c b/arch/arm64/kvm/mmio.c
> index 54f9358c9e0e..2a6261abb647 100644
> --- a/arch/arm64/kvm/mmio.c
> +++ b/arch/arm64/kvm/mmio.c
> @@ -159,6 +159,9 @@ int io_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa)
>   	bool is_write;
>   	int len;
>   	u8 data_buf[8];
> +	u64 esr;
> +
> +	esr = kvm_vcpu_get_esr(vcpu);
>   
>   	/*
>   	 * No valid syndrome? Ask userspace for help if it has
> @@ -168,7 +171,7 @@ int io_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa)
>   	 * though, so directly deliver an exception to the guest.
>   	 */
>   	if (!kvm_vcpu_dabt_isvalid(vcpu)) {
> -		trace_kvm_mmio_nisv(*vcpu_pc(vcpu), kvm_vcpu_get_esr(vcpu),
> +		trace_kvm_mmio_nisv(*vcpu_pc(vcpu), esr,
>   				    kvm_vcpu_get_hfar(vcpu), fault_ipa);
>   
>   		if (vcpu_is_protected(vcpu))
> @@ -185,6 +188,28 @@ int io_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa)
>   		return -ENOSYS;
>   	}
>   
> +	/*
> +	 * When (DFSC == 0b00xxxx || DFSC == 0b10101x) && DFSC != 0b0000xx
> +	 * ESR_EL2[12:11] describe the Load/Store Type. This allows us to
> +	 * punt the LD64B/ST64B/ST64BV/ST64BV0 instructions to luserspace,

minor nit: typo: s/luserspace/userspace/                       ^^^

> +	 * which will have to provide a full emulation of these 4
> +	 * instructions.  No, we don't expect this do be fast.
> +	 *
> +	 * We rely on traps being set if the corresponding features are not
> +	 * enabled, so if we get here, userspace has promised us to handle
> +	 * it already.
> +	 */
> +	switch (kvm_vcpu_trap_get_fault(vcpu)) {
> +	case 0b000100 ... 0b001111:
> +	case 0b101010 ... 0b101011:

Matches Arm ARM.

> +		if (FIELD_GET(GENMASK(12, 11), esr)) {
> +			run->exit_reason = KVM_EXIT_ARM_LDST64B;
> +			run->arm_nisv.esr_iss = esr & ~(u64)ESR_ELx_FSC;

Any particular reason why we diverge from the NISV case, where the FSC 
is provided, but not here ? May be this needs to be documented too.

Suzuki


> +			run->arm_nisv.fault_ipa = fault_ipa;
> +			return 0;
> +		}
> +	}
> +
>   	/*
>   	 * Prepare MMIO operation. First decode the syndrome data we get
>   	 * from the CPU. Then try if some in-kernel emulation feels
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 52f6000ab020..d219946b96be 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -179,6 +179,7 @@ struct kvm_xen_exit {
>   #define KVM_EXIT_LOONGARCH_IOCSR  38
>   #define KVM_EXIT_MEMORY_FAULT     39
>   #define KVM_EXIT_TDX              40
> +#define KVM_EXIT_ARM_LDST64B      41
>   
>   /* For KVM_EXIT_INTERNAL_ERROR */
>   /* Emulate instruction failed. */
> @@ -401,7 +402,7 @@ struct kvm_run {
>   		} eoi;
>   		/* KVM_EXIT_HYPERV */
>   		struct kvm_hyperv_exit hyperv;
> -		/* KVM_EXIT_ARM_NISV */
> +		/* KVM_EXIT_ARM_NISV / KVM_EXIT_ARM_LDST64B */
>   		struct {
>   			__u64 esr_iss;
>   			__u64 fault_ipa;





  reply	other threads:[~2025-11-07 11:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-07  7:21 [PATCH v7 0/7] Add support for FEAT_{LS64, LS64_V} and related tests Zhou Wang
2025-11-07  7:21 ` [PATCH v7 1/7] KVM: arm64: Add exit to userspace on {LD,ST}64B* outside of memslots Zhou Wang
2025-11-07 11:48   ` Suzuki K Poulose [this message]
2025-11-07 11:49     ` Suzuki K Poulose
2025-11-11  2:12     ` Zhou Wang
2025-11-07  7:21 ` [PATCH v7 2/7] KVM: arm64: Add documentation for KVM_EXIT_ARM_LDST64B Zhou Wang
2025-11-07  7:21 ` [PATCH v7 3/7] KVM: arm64: Handle DABT caused by LS64* instructions on unsupported memory Zhou Wang
2025-11-07  7:21 ` [PATCH v7 4/7] arm64: Provide basic EL2 setup for FEAT_{LS64, LS64_V} usage at EL0/1 Zhou Wang
2025-11-07  7:21 ` [PATCH v7 5/7] arm64: Add support for FEAT_{LS64, LS64_V} Zhou Wang
2025-11-07 12:05   ` Suzuki K Poulose
2025-11-11  3:40     ` Zhou Wang
2025-11-11 11:15   ` Marc Zyngier
2025-11-13 14:40     ` Zhou Wang
2025-11-13 16:26       ` Arnd Bergmann
2025-11-14  9:25         ` Zhou Wang
2025-11-14  9:37           ` Arnd Bergmann
2025-11-18  2:31             ` Zhou Wang
2025-11-18  7:36               ` Arnd Bergmann
2025-11-07  7:21 ` [PATCH v7 6/7] KVM: arm64: Enable FEAT_{LS64, LS64_V} in the supported guest Zhou Wang
2025-11-07 18:53   ` Oliver Upton
2025-11-11  3:43     ` Zhou Wang
2025-11-07  7:21 ` [PATCH v7 7/7] kselftest/arm64: Add HWCAP test for FEAT_{LS64, LS64_V} Zhou Wang
2025-11-07  9:21   ` Arnd Bergmann
2025-11-07  9:23 ` [PATCH v7 0/7] Add support for FEAT_{LS64, LS64_V} and related tests Arnd Bergmann
2025-11-07 18:57 ` Oliver Upton

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=1f0d24ae-c20c-4067-aa0c-b5bbeba367db@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=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=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;
as well as URLs for NNTP newsgroup(s).