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 14:53:49 +0100 [thread overview]
Message-ID: <arKB2imOcg4MhXMF@gremlin> (raw)
In-Reply-To: <yq5a8q4t305j.fsf@kernel.org>
On Tue, Sep 22, 2026 at 06:37:04PM +0530, Aneesh Kumar K.V wrote:
> "Lorenzo Stoakes (ARM)" <ljs@kernel.org> writes:
>
> > 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?
> >
>
> I am using this with ARM CCA-DA, based on the patch series from Jack Thomson <jackabt.amazon@gmail.com>.
>
> https://gitlab.arm.com/linux-arm/kvmtool-cca/-/commit/80e7aad61c5639de2f0cb4a5525dad0c96156428
>
> We do this while the VM is running.
Right, that's a non-mainline kernel I guess? Which presumably implements private memory.
Jack himself experienced a panic with his pKVM code, so the code you're using is
not upstreamable, unfortunately. And he'd already shelved pKVM support AFAICT.
And reviewers pointed out actually implementing the pKVM stuff properly would be
quite involved, even if you wanted to do that (hence follow-up).
Also you end up stuck with the same problems as I mentioned above - you can't
sanely bring the vCPU pre-run, so now you have extremely weird behaviour - only
pre-faults if vCPU initialised, running, and unprotected pKVM.
Protected pKVM support is a whole other layer of complexity and it's not obvious
that you're really achieving what pre-fault is supposed to.
In any case Oliver literally just asked me to _simplify_ weird edge cases for
this series :) so I am not sure something like that is going to be accepted.
Are you sure you're actually running in pKVM mode btw? CCA doesn't AFAICT? In
which case this series _should_ work fine for you.
Anyway, if we really do need to add something for pKVM it needs to be a follow
up. Let's get the basics working first :)
(Note that kvmtool will need to be updated to retry pre-fault on -EAGAIN, -EINTR
as this series can, albeit unlikely, return -EAGAIN.)
>
> -aneesh
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-09-22 13:53 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)
2026-09-22 13:07 ` Aneesh Kumar K.V
2026-09-22 13:53 ` Lorenzo Stoakes (ARM) [this message]
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=arKB2imOcg4MhXMF@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®