From: Marc Zyngier <maz@kernel.org>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Oliver Upton <oupton@kernel.org>,
Fuad Tabba <tabba@google.com>, Joey Gouly <joey.gouly@arm.com>,
Steffen Eiden <seiden@linux.ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kselftest@vger.kernel.org,
Jack Thomson <jackabt@amazon.com>,
Jack Thomson <jackabt.amazon@gmail.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Vincent Donnefort <vdonnefort@google.com>,
"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
Sean Christopherson <seanjc@google.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Leo Soares Passos <Leo.Bras@arm.com>
Subject: Re: [PATCH 3/8] KVM: arm64: Propagate and use kvm_s2_fault_result on S2 fault
Date: Thu, 10 Sep 2026 09:49:08 +0100 [thread overview]
Message-ID: <86v78d7apn.wl-maz@kernel.org> (raw)
In-Reply-To: <20260825-kvm-arm-prefault-v1-3-befe8947702e@kernel.org>
On Tue, 25 Aug 2026 17:00:37 +0100,
"Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:
>
> When stage 2 page tables fault the net result may either be that a page is
> mapped, an error occurred or the fault should be retried (-EAGAIN).
>
> When a fault succeeds it may be upgraded to a PMD size via
> transparent_hugepage_adjust().
>
> In order to support KVM pre-faulting the outcome of the fault and the
> mapping size must be recorded.
>
> Track this in the new kvm_s2_fault_result struct, which is threaded through
> gmem_abort(), user_mem_abort() and kvm_s2_fault_map().
>
> PKVM and SEA aren't relevant to synthetic pre-faulting so neither
> kvm_inject_sea() nor pkvm_mem_abort() are altered.
>
> Actual hardware faulting doesn't require this information, so
> kvm_handle_guest_abort() simply passes NULL kvm_s2_fault_result to
> gmem_abort() and user_mem_abort().
>
> Faults are necessarily ephemeral and pre-faulting can't guarantee what may
> happen in parallel, so do not store the GFN or PFN in
> kvm_s2_fault_result. Pre-faulting only needs to know what was mapped in at
> the point of the fault.
>
> This struct could be replaced with a pointer to an unsigned long, however
> it's clearer to separate out the mapped flag and having a struct allows us
> to easily add additional fields in future as needed.
>
> No functional change intended.
>
> Suggested-by: Vincent Donnefort <vdonnefort@google.com>
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
> arch/arm64/kvm/mmu.c | 33 +++++++++++++++++++++++++++------
> 1 file changed, 27 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 80cb520e25b9..da15da4e40e6 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1607,6 +1607,11 @@ struct kvm_s2_fault_desc {
> struct kvm_s2_mmu *mmu;
> };
>
> +struct kvm_s2_fault_result {
> + unsigned long mapping_size;
> + bool mapped;
> +};
> +
> static bool kvm_s2_fault_is_perm(const struct kvm_s2_fault_desc *s2fd)
> {
> return esr_fsc_is_permission_fault(s2fd->esr);
> @@ -1632,7 +1637,17 @@ static u64 kvm_s2_perm_fault_granule(const struct kvm_s2_fault_desc *s2fd)
> return BIT(ARM64_HW_PGTABLE_LEVEL_SHIFT(level));
> }
>
> -static int gmem_abort(const struct kvm_s2_fault_desc *s2fd)
> +static void populate_fault_result(struct kvm_s2_fault_result *result,
> + unsigned long mapping_size)
> +{
> + /* A THP upgrade may have altered mapping size. */
> + result->mapping_size = mapping_size;
> + /* -EAGAIN is swallowed so be explicit when we actually map. */
> + result->mapped = true;
I'm not sold on this boolean. I'd rather we use the fact that the
fault handler has passed a result pointer to return -EAGAIN rather
than turning into a 0, because that's a clear sign that the fault
hasn't been generated by a vcpu.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-09-10 8:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 16:00 [PATCH 0/8] KVM: arm64: Add KVM_PRE_FAULT_MEMORY support Lorenzo Stoakes (ARM)
2026-08-25 16:00 ` [PATCH 1/8] KVM: arm64: Propagate and use esr in s2fd when handling guest aborts Lorenzo Stoakes (ARM)
2026-09-10 8:39 ` Marc Zyngier
2026-09-10 9:04 ` Lorenzo Stoakes (ARM)
2026-08-25 16:00 ` [PATCH 2/8] KVM: arm64: Propagate and use mmu " Lorenzo Stoakes (ARM)
2026-08-25 16:00 ` [PATCH 3/8] KVM: arm64: Propagate and use kvm_s2_fault_result on S2 fault Lorenzo Stoakes (ARM)
2026-09-10 8:49 ` Marc Zyngier [this message]
2026-09-10 9:00 ` Lorenzo Stoakes (ARM)
2026-08-25 16:00 ` [PATCH 4/8] KVM: arm64: Pass walk flags to kvm_pgtable_get_leaf() Lorenzo Stoakes (ARM)
2026-08-25 16:00 ` [PATCH 5/8] KVM: arm64: Implement KVM_PRE_FAULT_MEMORY Lorenzo Stoakes (ARM)
2026-09-10 10:02 ` Marc Zyngier
2026-09-10 15:32 ` Lorenzo Stoakes (ARM)
2026-08-25 16:00 ` [PATCH 6/8] KVM: selftests: Enable pre_fault_memory_test for arm64 Lorenzo Stoakes (ARM)
2026-09-10 18:52 ` Fuad Tabba
2026-08-25 16:00 ` [PATCH 7/8] KVM: selftests: Add option for different backing in pre-fault tests Lorenzo Stoakes (ARM)
2026-08-25 16:00 ` [PATCH 8/8] KVM: selftests: Add nested pre-fault test for arm64 Lorenzo Stoakes (ARM)
2026-09-10 18:57 ` Fuad Tabba
2026-09-11 9:21 ` Lorenzo Stoakes (ARM)
2026-09-11 6:30 ` Itaru Kitayama
2026-09-11 9:32 ` Lorenzo Stoakes (ARM)
2026-09-11 12:42 ` Wei-Lin Chang
2026-09-11 15:44 ` Lorenzo Stoakes (ARM)
2026-09-10 18:44 ` [PATCH 0/8] KVM: arm64: Add KVM_PRE_FAULT_MEMORY support Fuad Tabba
2026-09-11 9:16 ` Lorenzo Stoakes (ARM)
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=86v78d7apn.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=Leo.Bras@arm.com \
--cc=alexandru.elisei@arm.com \
--cc=aneesh.kumar@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=imbrenda@linux.ibm.com \
--cc=jackabt.amazon@gmail.com \
--cc=jackabt@amazon.com \
--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=ljs@kernel.org \
--cc=oupton@kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=vdonnefort@google.com \
--cc=will@kernel.org \
--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.