On Tue, Sep 22, 2026, Lorenzo Stoakes (ARM) wrote:
> On Tue, Sep 22, 2026 at 10:23:43AM -0700, Sean Christopherson wrote:
> > Rather than have kvm_arch_vcpu_allow_pre_fault_memory(), what if we add a
> > more
> > generic kvm_is_vcpu_loadable()? That way we don't need to worry as much
> > about
> > the return value, the connection to vcpu_load() is obvious, and we don't
> > need to
> > add another pre-check if future (or cleaned-up existing?) ioctls want to do
> > vcpu_load() in common code.
>
> ...this is exactly what I started out with.
>
> But then you are in a pickle, because _really_ you need to do that check in
> vcpu_load(). Which is a void function. Which is called by every single
> architecture all over the place.
>
> So you'd have actually no way of signalling the error back.
>
> Of course those places are arch code and you could say 'arches should know
> better and if they call it it's fine not to call the arch 'can you load'
> function.
Yes, that's my vote. It'd be easy enough to clarify that "rule" with a comment
in linux/kvm_host.h.
> But you're still stuck with the problem of where exactly you put this check.
>
> So then do you put that check in a wrapper around it?
>
> Instead you can make the predicate 'don't prefault on a not-yet-initialised
> vCPU' which is pretty sensible I think, have a specific place to put it and
> all's well with the world.
But look at it from an x86 perspective. Pretty much everyone will look at this
and expect:
bool kvm_arch_vcpu_allow_pre_fault_memory(struct kvm_vcpu *vcpu)
{
return vcpu->kvm->arch.pre_fault_allowed;
}
> > I'd also be tempted to say it can be a macro, not a __weak function. E.g.
>
> Yeah it can be many things but why would you want a macro if you could
> possibly
> avoid it? :)
Because it allows arch code to dererefence "struct kvm_vcpu" in kvm_host.h,
i.e. allows "inlining" the check.
