On Wed, Aug 14, 2024, Vitaly Kuznetsov wrote: > What I meant is something along these lines (untested): > > diff --git a/arch/x86/kvm/vmx/vmx_onhyperv.h b/arch/x86/kvm/vmx/vmx_onhyperv.h > index eb48153bfd73..e2d8c67d0cad 100644 > --- a/arch/x86/kvm/vmx/vmx_onhyperv.h > +++ b/arch/x86/kvm/vmx/vmx_onhyperv.h > @@ -104,6 +104,14 @@ static inline void evmcs_load(u64 phys_addr) > struct hv_vp_assist_page *vp_ap = > hv_get_vp_assist_page(smp_processor_id()); > > + /* > + * When enabling eVMCS, KVM verifies that every CPU has a valid hv_vp_assist_page() > + * and aborts enabling the feature otherwise. CPU onlining path is also checked in > + * vmx_hardware_enable(). With this, it is impossible to reach here with vp_ap == NULL > + * but compilers may still complain. > + */ > + BUG_ON(!vp_ap); A full BUG_ON() is overkill, and easily avoided. If we want to add a sanity check here and do more than just WARN, then it's easy enough to plumb in @vcpu and make this a KVM_BUG_ON() so that the VM dies, i.e. so that KVM doesn't risk corrupting the guest somehow. > + > if (current_evmcs->hv_enlightenments_control.nested_flush_hypercall) > vp_ap->nested_control.features.directhypercall = 1; > vp_ap->current_nested_vmcs = phys_addr; > > the BUG_ON() will silence compiler warning as well as become a sentinel > for future code changes. > > -- > Vitaly >
