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: <bfeb4a317e08831e03707fad96ceb65dad286163.camel@redhat.com>
Subject: Re: [PATCH v3 05/34] KVM: x86: hyper-v: Expose support for extended
 gva ranges for flush hypercalls
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:   Wed, 11 May 2022 14:23:18 +0300
In-Reply-To: <20220414132013.1588929-6-vkuznets@redhat.com>
References: <20220414132013.1588929-1-vkuznets@redhat.com>
         <20220414132013.1588929-6-vkuznets@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-04-14 at 15:19 +0200, Vitaly Kuznetsov wrote:
> Extended GVA ranges support bit seems to indicate whether lower 12
> bits of GVA can be used to specify up to 4095 additional consequent
> GVAs to flush. This is somewhat described in TLFS.
> 
> Previously, KVM was handling HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST{,EX}
> requests by flushing the whole VPID so technically, extended GVA
> ranges were already supported. As such requests are handled more
> gently now, advertizing support for extended ranges starts making
> sense to reduce the size of TLB flush requests.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
>  arch/x86/include/asm/hyperv-tlfs.h | 2 ++
>  arch/x86/kvm/hyperv.c              | 1 +
>  2 files changed, 3 insertions(+)
> 
> diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h
> index 0a9407dc0859..5225a85c08c3 100644
> --- a/arch/x86/include/asm/hyperv-tlfs.h
> +++ b/arch/x86/include/asm/hyperv-tlfs.h
> @@ -61,6 +61,8 @@
>  #define HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE		BIT(10)
>  /* Support for debug MSRs available */
>  #define HV_FEATURE_DEBUG_MSRS_AVAILABLE			BIT(11)
> +/* Support for extended gva ranges for flush hypercalls available */
> +#define HV_FEATURE_EXT_GVA_RANGES_FLUSH			BIT(14)
>  /*
>   * Support for returning hypercall output block via XMM
>   * registers is available
> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
> index 759e1a16e5c3..1a6f9628cee9 100644
> --- a/arch/x86/kvm/hyperv.c
> +++ b/arch/x86/kvm/hyperv.c
> @@ -2702,6 +2702,7 @@ int kvm_get_hv_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid2 *cpuid,
>  			ent->ebx |= HV_DEBUGGING;
>  			ent->edx |= HV_X64_GUEST_DEBUGGING_AVAILABLE;
>  			ent->edx |= HV_FEATURE_DEBUG_MSRS_AVAILABLE;
> +			ent->edx |= HV_FEATURE_EXT_GVA_RANGES_FLUSH;
>  
>  			/*
>  			 * Direct Synthetic timers only make sense with in-kernel


I do think that we need to ask Microsoft to document this,
since from the spec (v6.0b) the only mention of this is 

"Bit 14: ExtendedGvaRangesForFlushVirtualAddressListAvailable"


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

Best regards,
	Maxim Levitsky