From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id F21C5324B2D for ; Fri, 7 Nov 2025 11:49:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762516158; cv=none; b=Tk9+850Zutcw3ZGLpKXdgBXm1xeJ/v1vn3ry2EyB1Q9YSlub60dyZBUz5aOGO9wAbqNU/TLLyCcEYzsrS+auYQeads53PNBRB7mVOxmBrW+PZbNUg+niFuYGJote0uoMilab5O7tqpXbuNdqqfuAcQB9PNMVb0xAIVXUOFbM/Fg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762516158; c=relaxed/simple; bh=QXmE58jWqTz+6fmUh4wbkTa0+b86LH+h73ZPYnF6l/4=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=EELpvt3G3DRP3y13IMP5yK7rAVkeBLittucMDkqprSskaspx5WdUzTazu6j9ft4rWjqVpsDswlaP50f9ip4HcFBHkWohrGyykfcONye7tJk3lIjUGnBoWadbB/4Q40coR+zXuKuAfs00d6laOE8zcMcRd8MRlonNJ039RXfHXds= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 55A9C1007; Fri, 7 Nov 2025 03:49:07 -0800 (PST) Received: from [10.1.197.1] (ewhatever.cambridge.arm.com [10.1.197.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6C8D33F63F; Fri, 7 Nov 2025 03:49:13 -0800 (PST) Message-ID: <75c46cdc-1843-4716-8f45-92c6c0b89248@arm.com> Date: Fri, 7 Nov 2025 11:49:11 +0000 Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 1/7] KVM: arm64: Add exit to userspace on {LD,ST}64B* outside of memslots From: Suzuki K Poulose To: Zhou Wang , 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 References: <20251107072127.448953-1-wangzhou1@hisilicon.com> <20251107072127.448953-2-wangzhou1@hisilicon.com> <1f0d24ae-c20c-4067-aa0c-b5bbeba367db@arm.com> Content-Language: en-US In-Reply-To: <1f0d24ae-c20c-4067-aa0c-b5bbeba367db@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 07/11/2025 11:48, Suzuki K Poulose wrote: > On 07/11/2025 07:21, Zhou Wang wrote: >> From: Marc Zyngier >> >> 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 >> Signed-off-by: Yicong Yang >> Signed-off-by: Zhou Wang > > We also need to document this new EXIT reason here : > > Documentation/virt/kvm/api.rst Well, spoke too soon. Please ignore this part ;-) > > >> --- >>   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; > > >