Re: [PATCH v2 00/13] KVM: arm64: Add KVM_PRE_FAULT_MEMORY support

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Tue, Sep 22, 2026 at 07:52:25PM +0530, Aneesh Kumar K.V wrote:
> "Lorenzo Stoakes (ARM)" <ljs@kernel.org> writes:
>
> > 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.
> >
>
> IIUC, pkvm_pgtable_stage2_map() only uses the hyp vCPU's pKVM memcache
> (&vcpu->vcpu.arch.pkvm_memcache). I agree that this does not need to be
> addressed in this series. However, there is also a desire to keep the CCA
> and pKVM code paths similar by using helpers such as kvm_vm_is_protected().
> Since an RMM can create a stage-2 mapping without a REC (vCPU), rejecting
> pre-faulting for all protected VM configurations may be incorrect. I can
> handle this in my series though.

Ack, understood. Feel free to cc- me on that when you send it out!

>
> I also want to point out that there are use cases for pre-faulting while
> the VM is running.

Ack yeah understood! And it does support that fine :)

I added further reasoning about pKVM in the cover/commit msg in the respin
([0]) so hopefully that helps clarify from that sid eof things.


>
> >
> > 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.
> >
>
>
> It is not pKVM; it runs in Realm mode.

Ack yeah, then the series should hopefully work for you.

If you could test it and report any issues I'd be grateful! Thanks :)

>
> >
> > 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 :)
> >
>
> sure.

Thanks!

>
> > (Note that kvmtool will need to be updated to retry pre-fault on -EAGAIN, -EINTR
> >  as this series can, albeit unlikely, return -EAGAIN.)
> >
>
> I will check this when I rebase my kernel onto this series.

OK cool, let me know if you hit any issues.

>
> -aneesh

--
Cheers, Lorenzo

[0]: https://lore.kernel.org/kvmarm/20260922-kvm-arm-prefault-v3-0-787bd3bc7e3f@kernel.org/T/#t