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

Sean Christopherson
2021-11-05T14:28:33Z

On Fri, Nov 05, 2021, Vitaly Kuznetsov wrote:
> Sean Christopherson <seanjc@google.com> 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;