Re: [PATCH v3 3/4] KVM: nVMX: Track whether changes in L0 require MSR bitmap for L2 to be rebuilt

[Sean Christopherson]

On Fri, Nov 05, 2021, Vitaly Kuznetsov wrote:
> Sean Christopherson <seanjc@xxxxxxxxxx> writes:
> 
> > On Wed, Oct 13, 2021, Vitaly Kuznetsov wrote:
> >> diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
> >> index 592217fd7d92..2cdf66e6d1b0 100644
> >> --- a/arch/x86/kvm/vmx/vmx.h
> >> +++ b/arch/x86/kvm/vmx/vmx.h
> >> @@ -148,6 +148,15 @@ struct nested_vmx {
> >>  	bool need_vmcs12_to_shadow_sync;
> >>  	bool dirty_vmcs12;
> >>  
> >> +	/*
> >> +	 * Indicates whether MSR bitmap for L2 needs to be rebuilt due to
> >> +	 * changes in MSR bitmap for L1 or switching to a different L2. Note,
> >> +	 * this flag can only be used reliably in conjunction with a paravirt L1
> >> +	 * which informs L0 whether any changes to MSR bitmap for L2 were done
> >> +	 * on its side.
> >> +	 */
> >> +	bool msr_bitmap_force_recalc;
> >
> > Belated bikeshedding...  What about need_msr_bitmap_recalc to follow the above
> > need_vmcs12_to_shadow_sync?
> >
> 
> 'msr_bitmap_force_recalc' was suggested by Paolo but
> 'need_msr_bitmap_recalc' sounds equally good to me.

Ah, actually, Paolo's is better.  "!need" implies that the recalc can be skipped
regardless of any other behavior, whereas "!force" provides the hint that a recalc
may still be needed for other reasons.

Can we move the "force" to the front though, i.e. force_msr_bitmap_recalc?  The
other fields in nested_vmx all have the verb at the front.

	bool need_vmcs12_to_shadow_sync;
	bool need_sync_vmcs02_to_vmcs12_rare;
	bool change_vmcs01_virtual_apic_mode;
	bool reload_vmcs01_apic_access_page;
	bool update_vmcs01_cpu_dirty_logging;