From: Leonardo Bras <leo.bras@arm.com>
To: Tian Zheng <zhengtian10@huawei.com>
Cc: Leonardo Bras <leo.bras@arm.com>,
maz@kernel.org, oupton@kernel.org, catalin.marinas@arm.com,
will@kernel.org, corbet@lwn.net, pbonzini@redhat.com,
yuzenghui@huawei.com, wangzhou1@hisilicon.com,
yangjinqian1@huawei.com, caijian11@h-partners.com,
liuyonglong@huawei.com, tangchengchang@huawei.com,
yezhenyu2@huawei.com, yubihong@huawei.com, linuxarm@huawei.com,
joey.gouly@arm.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, seiden@linux.ibm.com,
suzuki.poulose@arm.com, fuad.tabba@linux.dev,
mark.rutland@arm.com, seanjc@google.com, rdunlap@infradead.org,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
skhan@linuxfoundation.org
Subject: Re: [PATCH v5 09/15] KVM: arm64: Handle HDBSS faults
Date: Mon, 2 Nov 2026 14:34:03 +0000 [thread overview]
Message-ID: <auifWrY1u72afXfJ@LeoBrasDK> (raw)
In-Reply-To: <20260929103655.85107-10-zhengtian10@huawei.com>
On Tue, Sep 29, 2026 at 06:36:49PM +0800, Tian Zheng wrote:
> From: Eillon <yezhenyu2@huawei.com>
>
> Once the buffer is full, hardware stops promoting writable-clean
> descriptors and raises a stage-2 Permission fault with
> ESR_EL2.ISS2.HDBSSF instead. Failed HDBSS accesses, such as external
> aborts and granule protection faults, are reported the same way.
>
> Dispatch from kvm_handle_guest_abort() via the new esr_iss2_is_hdbssf()
> helper. FSC == OK means the exit path already flushed, so resume the
> guest; any other FSC is an error - clear it and report -EFAULT.
>
> Signed-off-by: Eillon <yezhenyu2@huawei.com>
> Signed-off-by: Tian Zheng <zhengtian10@huawei.com>
> ---
> arch/arm64/include/asm/esr.h | 5 +++++
> arch/arm64/include/asm/kvm_dirty_bit.h | 1 +
> arch/arm64/kvm/dirty_bit.c | 29 ++++++++++++++++++++++++++
> arch/arm64/kvm/mmu.c | 4 ++++
> 4 files changed, 39 insertions(+)
>
> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
> index f816f5d77f1a..4b3ccd407faa 100644
> --- a/arch/arm64/include/asm/esr.h
> +++ b/arch/arm64/include/asm/esr.h
> @@ -437,6 +437,11 @@
> #ifndef __ASSEMBLER__
> #include <asm/types.h>
>
> +static inline bool esr_iss2_is_hdbssf(unsigned long esr)
> +{
> + return !!(ESR_ELx_ISS2(esr) & ESR_ELx_HDBSSF);
> +}
> +
> static inline unsigned long esr_brk_comment(unsigned long esr)
> {
> return esr & ESR_ELx_BRK64_ISS_COMMENT_MASK;
> diff --git a/arch/arm64/include/asm/kvm_dirty_bit.h b/arch/arm64/include/asm/kvm_dirty_bit.h
> index d828e6b43fe9..eb2039820777 100644
> --- a/arch/arm64/include/asm/kvm_dirty_bit.h
> +++ b/arch/arm64/include/asm/kvm_dirty_bit.h
> @@ -39,5 +39,6 @@ static inline bool vcpu_hdbss_enabled(struct kvm_vcpu *vcpu)
> int kvm_arm_vcpu_alloc_hdbss(struct kvm_vcpu *vcpu);
> void kvm_arm_vcpu_free_hdbss(struct kvm_vcpu *vcpu);
> void kvm_flush_hdbss_buffer(struct kvm_vcpu *vcpu);
> +int kvm_handle_hdbss_fault(struct kvm_vcpu *vcpu);
>
> #endif /* __ARM64_KVM_DIRTY_BIT_H__ */
> diff --git a/arch/arm64/kvm/dirty_bit.c b/arch/arm64/kvm/dirty_bit.c
> index be0d12555c84..893a8c4248bc 100644
> --- a/arch/arm64/kvm/dirty_bit.c
> +++ b/arch/arm64/kvm/dirty_bit.c
> @@ -98,3 +98,32 @@ void kvm_flush_hdbss_buffer(struct kvm_vcpu *vcpu)
> vcpu->arch.hdbss.hdbssprod_el2 = prod;
> isb();
> }
> +
> +int kvm_handle_hdbss_fault(struct kvm_vcpu *vcpu)
> +{
> + u64 prod;
> + u64 fsc;
> +
> + if (WARN_ON_ONCE(!system_supports_hdbss()))
> + return -EFAULT;
> +
> + if (WARN_ON_ONCE(!vcpu_hdbss_enabled(vcpu)))
> + return -EFAULT;
> +
> + prod = read_sysreg_s(SYS_HDBSSPROD_EL2);
> + fsc = FIELD_GET(HDBSSPROD_EL2_FSC_MASK, prod);
> +
> + if (fsc == HDBSSPROD_EL2_FSC_OK)
> + /* Buffer full: the exit path drained it before handle_exit. */
> + return 1;
> +
> + if (fsc != HDBSSPROD_EL2_FSC_ExternalAbort &&
> + fsc != HDBSSPROD_EL2_FSC_GPF)
> + WARN_ONCE(1,
> + "Unexpected HDBSS fault type, FSC: 0x%llx (prod=0x%llx, vcpu=%d)\n",
> + fsc, prod, vcpu->vcpu_id);
Any reason for using if() before warn_once, given the first parameter is a
condition? I mean, why not use, instead:
+ WARN_ONCE(fsc != HDBSSPROD_EL2_FSC_ExternalAbort &&
+ fsc != HDBSSPROD_EL2_FSC_GPF,
+ "Unexpected HDBSS fault type, FSC: 0x%llx (prod=0x%llx, vcpu=%d)\n",
+ fsc, prod, vcpu->vcpu_id);
> +
> + /* Clear FSC so hardware dirty state updates can resume. */
> + write_sysreg_s(prod & ~HDBSSPROD_EL2_FSC_MASK, SYS_HDBSSPROD_EL2);
> + return -EFAULT;
> +}
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 85a98d2c23a9..7bf82d65041c 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -15,6 +15,7 @@
> #include <asm/pgalloc.h>
> #include <asm/cacheflush.h>
> #include <asm/kvm_arm.h>
> +#include <asm/kvm_dirty_bit.h>
> #include <asm/kvm_mmu.h>
> #include <asm/kvm_pgtable.h>
> #include <asm/kvm_pkvm.h>
> @@ -2315,6 +2316,9 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
>
> is_iabt = kvm_vcpu_trap_is_iabt(vcpu);
>
> + if (esr_iss2_is_hdbssf(esr))
> + return kvm_handle_hdbss_fault(vcpu);
> +
> if (esr_fsc_is_translation_fault(esr)) {
> /* Beyond sanitised PARange (which is the IPA limit) */
> if (fault_ipa >= BIT_ULL(get_kvm_ipa_limit())) {
I did not get the criteria used to positioning it here:
Why placed before is_abt, if not using the result before returning?
What is the rationale to putting it here?
Thanks!
Leo
next prev parent reply other threads:[~2026-11-02 14:34 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 10:36 [PATCH v5 00/15] KVM: arm64: FEAT_HDBSS support for stage-2 dirty tracking Tian Zheng
2026-09-29 10:36 ` [PATCH v5 01/15] KVM: arm64: pgtables: Change write bit from S2AP_W to DBM Tian Zheng
2026-09-30 0:25 ` Oliver Upton
2026-09-30 2:44 ` Tian Zheng
2026-10-26 15:02 ` Leonardo Bras
2026-10-29 7:08 ` Tian Zheng
2026-09-29 10:36 ` [PATCH v5 02/15] KVM: arm64: Add KVM_PGTABLE_PROT_DIRTY Tian Zheng
2026-09-30 0:35 ` Oliver Upton
2026-09-30 2:57 ` Tian Zheng
2026-09-29 10:36 ` [PATCH v5 03/15] KVM: arm64: Introduce a dedicated walker for stage2 write-protect Tian Zheng
2026-09-29 10:36 ` [PATCH v5 04/15] KVM: arm64: Add KVM_REQ_RELOAD_STAGE2 Tian Zheng
2026-09-29 10:50 ` sashiko-bot
2026-09-30 1:44 ` Tian Zheng
2026-09-29 10:36 ` [PATCH v5 05/15] KVM: arm64: Harvest stage-2 dirty state into the host folio account Tian Zheng
2026-10-26 18:05 ` Leonardo Bras
2026-10-29 14:02 ` Tian Zheng
2026-10-30 12:24 ` Leonardo Bras
2026-11-06 3:16 ` Tian Zheng
2026-11-06 12:04 ` Leonardo Bras
2026-09-29 10:36 ` [PATCH v5 06/15] KVM: arm64: Add support for FEAT_HDBSS Tian Zheng
2026-10-26 18:12 ` Leonardo Bras
2026-10-30 2:53 ` Tian Zheng
2026-10-30 14:15 ` Leonardo Bras
2026-09-29 10:36 ` [PATCH v5 07/15] KVM: arm64: Add HDBSS per-vCPU buffer management Tian Zheng
2026-10-26 18:27 ` Leonardo Bras
2026-10-30 3:47 ` Tian Zheng
2026-10-30 14:47 ` Leonardo Bras
2026-11-06 8:49 ` Tian Zheng
2026-11-06 15:21 ` Leonardo Bras
2026-09-29 10:36 ` [PATCH v5 08/15] KVM: arm64: Flush the HDBSS buffer on VM exit Tian Zheng
2026-10-27 18:13 ` Leonardo Bras
2026-10-30 4:57 ` Tian Zheng
2026-10-30 16:52 ` Leonardo Bras
2026-11-06 9:02 ` Tian Zheng
2026-09-29 10:36 ` [PATCH v5 09/15] KVM: arm64: Handle HDBSS faults Tian Zheng
2026-09-29 10:53 ` sashiko-bot
2026-11-09 7:36 ` Tian Zheng
2026-11-02 14:34 ` Leonardo Bras [this message]
2026-11-06 9:44 ` Tian Zheng
2026-09-29 10:36 ` [PATCH v5 10/15] KVM: Add kvm_arch_dirty_ring_size_updated() hook Tian Zheng
2026-09-29 10:52 ` sashiko-bot
2026-11-09 6:37 ` Tian Zheng
2026-09-29 10:36 ` [PATCH v5 11/15] KVM: arm64: Reserve dirty ring space for the HDBSS buffer Tian Zheng
2026-09-29 11:00 ` sashiko-bot
2026-11-09 10:03 ` Tian Zheng
2026-11-09 18:07 ` Leonardo Bras
2026-11-02 14:54 ` Leonardo Bras
2026-11-06 10:36 ` Tian Zheng
2026-11-06 15:36 ` Leonardo Bras
2026-11-09 4:00 ` Tian Zheng
2026-11-09 18:18 ` Leonardo Bras
2026-11-10 8:54 ` Tian Zheng
2026-11-10 12:49 ` Leonardo Bras
2026-11-12 13:15 ` Tian Zheng
2026-11-12 15:26 ` Leonardo Bras
2026-11-06 10:58 ` Tian Zheng
2026-09-29 10:36 ` [PATCH v5 12/15] KVM: arm64: Derive the VM hardware dirty mode from dirty logging Tian Zheng
2026-09-29 11:16 ` sashiko-bot
2026-09-30 8:27 ` Tian Zheng
2026-11-02 15:03 ` Leonardo Bras
2026-11-06 10:46 ` Tian Zheng
2026-11-06 15:37 ` Leonardo Bras
2026-09-29 10:36 ` [PATCH v5 13/15] KVM: arm64: Add HDBSS buffer size ioctl for dirty-bitmap mode Tian Zheng
2026-11-02 15:12 ` Leonardo Bras
2026-11-06 10:27 ` Tian Zheng
2026-11-06 15:37 ` Leonardo Bras
2026-09-29 10:36 ` [PATCH v5 14/15] KVM: arm64: Document HDBSS buffer size ioctl Tian Zheng
2026-09-29 11:06 ` sashiko-bot
2026-09-29 10:36 ` [PATCH v5 15/15] KVM: arm64: selftests: Add HDBSS buffer size ioctl interface test Tian Zheng
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=auifWrY1u72afXfJ@LeoBrasDK \
--to=leo.bras@arm.com \
--cc=caijian11@h-partners.com \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=fuad.tabba@linux.dev \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=liuyonglong@huawei.com \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=pbonzini@redhat.com \
--cc=rdunlap@infradead.org \
--cc=seanjc@google.com \
--cc=seiden@linux.ibm.com \
--cc=skhan@linuxfoundation.org \
--cc=suzuki.poulose@arm.com \
--cc=tangchengchang@huawei.com \
--cc=wangzhou1@hisilicon.com \
--cc=will@kernel.org \
--cc=yangjinqian1@huawei.com \
--cc=yezhenyu2@huawei.com \
--cc=yubihong@huawei.com \
--cc=yuzenghui@huawei.com \
--cc=zhengtian10@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.