Re: [PATCH v2 3/8] KVM: x86/hyperv: Ensure vCPU's Hyper-V object is initialized on cross-vCPU accesses

[Sean Christopherson <seanjc@google.com>]

On Fri, Jun 12, 2026, sashiko-bot@kernel.org wrote:
> > diff --git a/arch/x86/kvm/hyperv.h b/arch/x86/kvm/hyperv.h
> > index e6c74cfbb1cb6..821b586ed7464 100644
> > --- a/arch/x86/kvm/hyperv.h
> > +++ b/arch/x86/kvm/hyperv.h
> > @@ -61,6 +61,18 @@ static inline struct kvm_hv *to_kvm_hv(struct kvm *kvm)
> >  	return &kvm->arch.hyperv;
> >  }
> >  
> > +static inline struct kvm_vcpu_hv *to_hv_vcpu_safe(struct kvm_vcpu *vcpu)
> > +{
> > +	/*
> > +	 * Ensure the HyperV structure is fully initialized when accessing it
> > +	 * without holding vcpu->mutex (or some other guarantee that KVM can't
> > +	 * concurrently instantiate the structure).
> > +	 *
> > +	 * Pairs with the smp_store_release() in kvm_hv_vcpu_init().
> > +	 */
> > +	return smp_load_acquire(&vcpu->arch.hyperv);
> > +}
> > +
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but should 
> kvm_hv_has_stimer_pending() also be updated to use to_hv_vcpu_safe()?
> 
> It currently still uses the unsafe to_hv_vcpu() accessor:
> 
> static inline bool kvm_hv_has_stimer_pending(struct kvm_vcpu *vcpu)
> {
> 	struct kvm_vcpu_hv *hv_vcpu = to_hv_vcpu(vcpu);
> 	...
> 
> Since kvm_hv_has_stimer_pending() can be reached cross-vCPU without holding
> the target vcpu->mutex via the spin-loop yield path:
> 
> kvm_vcpu_on_spin() -> vcpu_dy_runnable() -> kvm_arch_dy_runnable() ->
> kvm_arch_vcpu_runnable() -> kvm_vcpu_has_events() ->
> kvm_hv_has_stimer_pending()
> 
> Could this bypass the necessary memory barriers and result in reading an
> uninitialized stimer_pending_bitmap?
> 
> Also, won't using the unsafe accessor here unconditionally trigger the lockdep
> assertion introduced later in the series when accessed cross-vCPU?

*sigh*

Yes and yes.