From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Marc Zyngier <maz@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>,
Sean Christopherson <seanjc@google.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Leo Soares Passos <Leo.Bras@arm.com>
Subject: Re: [PATCH v2 00/13] KVM: arm64: Add KVM_PRE_FAULT_MEMORY support
Date: Tue, 22 Sep 2026 13:52:07 +0100 [thread overview]
Message-ID: <arJ1BDEzY5CANjjB@gremlin> (raw)
In-Reply-To: <yq5abj9p38vq.fsf@kernel.org>
On Tue, Sep 22, 2026 at 03:28:33PM +0530, Aneesh Kumar K.V wrote:
> > This is because pKVM instantiates vCPUs upon run,
> >
>
> Can pKVM instantiate the hyp vCPU during pre-faulting ?
It would be an unusual and unexpected thing to do - suddenly a pre-fault
operation is initialising a vCPU explicitly for pKVM.
A caller is not going to reasonably expect this and might treat a failure to
pre-alloc as fine to carry on whereas in fact it was a failure to initailised a
pKVM vCPU.
It'd also require significant changes to how pKVM is set up, right now it's
hardcoded to be done unconditionally at run via kvm_arch_vcpu_run_pid_change()
-> pkvm_create_hyp_vcpu(), so all that would have to change and be checked and
tested and... that'd be really out of scope I think :)
And pre-faulting really makes most sense BEFORE you run a VM. It doesn't make so
much sense mid-run.
But more fundamentally, the stage 2 page tables, as I understand it, are owned
by pKVM and so aren't really available to be pre-faulted.
Maybe unprotected-under-pKVM VMs but then it's questionable as to how useful
that would be given that it would be confusing to users vs. how it works for
other VMs.
So in general, no I don't think it's a good idea.
And even if we wanted to pursue some version of this, it's _definitely_ out
of scope for the initial pre-faulting bring-up series.
>
>
> > but pre-faulting is typically performed before a vCPU is run. It would be confusing and
> > inconsistent to error out on non-running vCPUs but to pre-fault running
> > ones.
>
>
> I use KVM pre-faulting when transitioning pages from shared to private
You mean you'd prefer to use? Or you are using it on another arch?
> with CoCo guest. This ensures that a trusted device can DMA to private
> memory before the guest accesses it.
Hm what do you mean by private memory?
I see:
#ifndef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
{
return false;
}
#endif
And only x86 selects KVM_GENERIC_MEMORY_ATTRIBUTES?
Do you mean something else?
Or are you saying we should match x86? I don't think we have the same
semantics as them, I don't think there's an equivalent for us, and of
course no private memory in the sense of the predicate above.
In any case I think anything wanting to add additional functionality to
pre-faulting would have to be a follow-up anyway.
>
> -aneesh
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-09-22 12:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 12:26 Lorenzo Stoakes (ARM)
2026-09-14 12:26 ` [PATCH v2 01/13] arm64: Add ESR fault helpers Lorenzo Stoakes (ARM)
2026-09-14 12:26 ` [PATCH v2 02/13] KVM: arm64: Use ESR helpers in guest abort handling Lorenzo Stoakes (ARM)
2026-09-14 12:26 ` [PATCH v2 03/13] KVM: arm64: Propagate and use esr in s2fd when handling guest aborts Lorenzo Stoakes (ARM)
2026-09-14 12:26 ` [PATCH v2 04/13] KVM: arm64: Propagate and use mmu " Lorenzo Stoakes (ARM)
2026-09-14 12:26 ` [PATCH v2 05/13] KVM: arm64: Propagate and use kvm_s2_fault_result on S2 fault Lorenzo Stoakes (ARM)
2026-09-14 12:26 ` [PATCH v2 06/13] KVM: arm64: Size the stage-2 memcache from the fault MMU Lorenzo Stoakes (ARM)
2026-09-14 12:26 ` [PATCH v2 07/13] KVM: arm64: Propagate EHWPOISON in kvm_s2_fault_pin_pfn() Lorenzo Stoakes (ARM)
2026-09-14 12:26 ` [PATCH v2 08/13] KVM: arm64: Pass walk flags to kvm_pgtable_get_leaf() Lorenzo Stoakes (ARM)
2026-09-14 12:26 ` [PATCH v2 09/13] KVM: arm64: Implement KVM_PRE_FAULT_MEMORY Lorenzo Stoakes (ARM)
2026-09-14 12:26 ` [PATCH v2 10/13] Documentation: KVM: document arm64 KVM_PRE_FAULT_MEMORY Lorenzo Stoakes (ARM)
2026-09-14 12:26 ` [PATCH v2 11/13] KVM: selftests: Enable pre_fault_memory_test for arm64 Lorenzo Stoakes (ARM)
2026-09-14 12:26 ` [PATCH v2 12/13] KVM: selftests: Add option for different backing in pre-fault tests Lorenzo Stoakes (ARM)
2026-09-14 12:26 ` [PATCH v2 13/13] KVM: selftests: Add nested pre-fault test for arm64 Lorenzo Stoakes (ARM)
2026-09-22 9:58 ` [PATCH v2 00/13] KVM: arm64: Add KVM_PRE_FAULT_MEMORY support Aneesh Kumar K.V
2026-09-22 12:52 ` Lorenzo Stoakes (ARM) [this message]
2026-09-22 13:07 ` Aneesh Kumar K.V
2026-09-22 13:53 ` Lorenzo Stoakes (ARM)
2026-09-22 14:22 ` Aneesh Kumar K.V
2026-09-22 14:26 ` 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=arJ1BDEzY5CANjjB@gremlin \
--to=ljs@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=maz@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®