Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <cb54921d6834ff2b4eda61b78c423125ca315d7d.camel@redhat.com>
Subject: Re: [PATCH v3 17/34] KVM: x86: hyper-v: Introduce fast
 kvm_hv_l2_tlb_flush_exposed() check
From:   Maxim Levitsky <mlevitsk@redhat.com>
To:     Vitaly Kuznetsov <vkuznets@redhat.com>, kvm@vger.kernel.org,
        Paolo Bonzini <pbonzini@redhat.com>
Cc:     Sean Christopherson <seanjc@google.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Michael Kelley <mikelley@microsoft.com>,
        Siddharth Chandrasekaran <sidcha@amazon.de>,
        linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
Date:   Thu, 19 May 2022 16:28:06 +0300
In-Reply-To: <877d6hu012.fsf@redhat.com>
References: <20220414132013.1588929-1-vkuznets@redhat.com>
         <20220414132013.1588929-18-vkuznets@redhat.com>
         <3a4199c0b7ba7cf82c4eadf2881e24be609c2f0d.camel@redhat.com>
         <877d6hu012.fsf@redhat.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Thu, 2022-05-19 at 15:25 +0200, Vitaly Kuznetsov wrote:
> Maxim Levitsky <mlevitsk@redhat.com> writes:
> 
> > On Thu, 2022-04-14 at 15:19 +0200, Vitaly Kuznetsov wrote:
> > > Introduce a helper to quickly check if KVM needs to handle VMCALL/VMMCALL
> > > from L2 in L0 to process L2 TLB flush requests.
> > > 
> > > Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> > > ---
> > >  arch/x86/include/asm/kvm_host.h | 1 +
> > >  arch/x86/kvm/hyperv.c           | 6 ++++++
> > >  arch/x86/kvm/hyperv.h           | 7 +++++++
> > >  3 files changed, 14 insertions(+)
> > > 
> > > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> > > index ce62fde5f4ff..168600490bd1 100644
> > > --- a/arch/x86/include/asm/kvm_host.h
> > > +++ b/arch/x86/include/asm/kvm_host.h
> > > @@ -616,6 +616,7 @@ struct kvm_vcpu_hv {
> > >  		u32 enlightenments_eax; /* HYPERV_CPUID_ENLIGHTMENT_INFO.EAX */
> > >  		u32 enlightenments_ebx; /* HYPERV_CPUID_ENLIGHTMENT_INFO.EBX */
> > >  		u32 syndbg_cap_eax; /* HYPERV_CPUID_SYNDBG_PLATFORM_CAPABILITIES.EAX */
> > > +		u32 nested_features_eax; /* HYPERV_CPUID_NESTED_FEATURES.EAX */
> > >  	} cpuid_cache;
> > >  
> > >  	struct kvm_vcpu_hv_tlb_flush_ring tlb_flush_ring[HV_NR_TLB_FLUSH_RINGS];
> > > diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
> > > index 79aabe0c33ec..68a0df4e3f66 100644
> > > --- a/arch/x86/kvm/hyperv.c
> > > +++ b/arch/x86/kvm/hyperv.c
> > > @@ -2281,6 +2281,12 @@ void kvm_hv_set_cpuid(struct kvm_vcpu *vcpu)
> > >  		hv_vcpu->cpuid_cache.syndbg_cap_eax = entry->eax;
> > >  	else
> > >  		hv_vcpu->cpuid_cache.syndbg_cap_eax = 0;
> > > +
> > > +	entry = kvm_find_cpuid_entry(vcpu, HYPERV_CPUID_NESTED_FEATURES, 0);
> > > +	if (entry)
> > > +		hv_vcpu->cpuid_cache.nested_features_eax = entry->eax;
> > > +	else
> > > +		hv_vcpu->cpuid_cache.nested_features_eax = 0;
> > >  }
> > >  
> > >  int kvm_hv_set_enforce_cpuid(struct kvm_vcpu *vcpu, bool enforce)
> > > diff --git a/arch/x86/kvm/hyperv.h b/arch/x86/kvm/hyperv.h
> > > index f593c9fd1dee..d8cb6d70dbc8 100644
> > > --- a/arch/x86/kvm/hyperv.h
> > > +++ b/arch/x86/kvm/hyperv.h
> > > @@ -168,6 +168,13 @@ static inline void kvm_hv_vcpu_empty_flush_tlb(struct kvm_vcpu *vcpu)
> > >  	tlb_flush_ring->read_idx = tlb_flush_ring->write_idx;
> > >  }
> > >  
> > > +static inline bool kvm_hv_l2_tlb_flush_exposed(struct kvm_vcpu *vcpu)
> > > +{
> > > +	struct kvm_vcpu_hv *hv_vcpu = to_hv_vcpu(vcpu);
> > > +
> > > +	return hv_vcpu && (hv_vcpu->cpuid_cache.nested_features_eax & HV_X64_NESTED_DIRECT_FLUSH);
> > > +}
> > 
> > Tiny nipick (feel free to ignore): maybe use 'supported' instead of 'exposed',
> > as we don't use this term in KVM often.
> > 
> 
> Indeed we don't. Basically, this is guest_cpuid_has() but for a Hyper-V
> bit. I don't quite like 'supported' because we don't actually check
> whether KVM or even L1 guest 'support' this feature or not, we check
> whether the feature was 'exposed' to L1 so it can actually use it. I'm
> going to rename this to
> 
>  guest_hv_cpuid_has_l2_tlb_flush()
Sounds perfect!

Best regards,
	Maxim Levitsky

> 
> then.
> 
> > Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
> > 
> 
> Thanks!
>