From patchwork Fri Oct 21 15:34:47 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vitaly Kuznetsov X-Patchwork-Id: 6772 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp765641wrr; Fri, 21 Oct 2022 08:40:01 -0700 (PDT) X-Google-Smtp-Source: AMsMyM59Cn1rLINIladASf14aIf4kYJPjtMIcW837C9GlsnfqNuEHsYALyRAMAXiYr3+ZC+QY9AU X-Received: by 2002:a17:907:2d09:b0:78d:4240:a45e with SMTP id gs9-20020a1709072d0900b0078d4240a45emr16226489ejc.350.1666366800805; Fri, 21 Oct 2022 08:40:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666366800; cv=none; d=google.com; s=arc-20160816; b=RuyB6asaJ1jKgg/ajR8jVr/Znwdpe7cq3SxMe9JoeeSG5G+VADBSVTTgzj8m+UJKxw 7el7bnNDDYXPyhr61Z2Fec5JYDw01hrPIX0xcpyMtVaSaVKdaTQgX5SZsT1LQjSzmera Xf33pZhyrNY8fDMFwF246UnlKpZA5m3UoQ0hnIN8Ds2yTlKt2LTD+zmamWVWeA8lSIXP XMVEp0Hkv/K16IDoweosC9ZS23Zlhqx2Dr/XXK3jA711zcARIV2RYRvE/u20IRI2g4ty PvQVE7G6e0RrrXVzgpyd6Quq5VPpIsZM1pWViUKIGWk5fFnVPhhzPJJED0UMvndwEMho 5wZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=yIvTkYPHNFLdIXKJtaTQVmHdNYsEitjgdEe7z9qTIys=; b=gLVy5cxtvin3GfwVKYrRLASu8YBoytf853fYRLBNJ25R6oKHMJ2HbhW/5e2nPe9QCL CRCOVpbCrbfYgddkXU2Ky7bI0bCeE7T4se1tiGAshGdXIbzZP5dGM9sgTRI5HW8vKDyR mhkTgB87pMJxzqorZXQ7O5yhhAgxILfgkhDKeJb+Ln53xa7crD2JhHp0BuegnjrPnFC/ CRYj/Q2NjCl7aCebt6a22HR4LHXcioiiHWgduCgg1x6B5DgWCHEInthcH6x45VQt3Yc6 q6PC0UofCpGXRDiaECeKH9sgx+fyNNeyB7M1plBnji1UplbohwbRkfeEaojqjH83Wph0 +zPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JuA2oquH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g13-20020a056402090d00b00458b71488bdsi23885532edz.388.2022.10.21.08.39.34; Fri, 21 Oct 2022 08:40:00 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JuA2oquH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230349AbiJUPgz (ORCPT + 99 others); Fri, 21 Oct 2022 11:36:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45550 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230406AbiJUPgW (ORCPT ); Fri, 21 Oct 2022 11:36:22 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 128CD26D915 for ; Fri, 21 Oct 2022 08:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666366560; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yIvTkYPHNFLdIXKJtaTQVmHdNYsEitjgdEe7z9qTIys=; b=JuA2oquHPYVZqskOWIj6U8vqR5ytgZpkSeGZKnjfwg0UnFhgWKAKyMm6IHAkHQ0bsShDiO PoPDm+mW6LJDvy8extHRKkTZjD6H2sHCVpF6CadLZO0q++bVo18NSUO5w27E6LkBsvG3ZL 0VX7IxDcA7eLE84Pt5/gvFp5uCnlFE4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-222-lnmOZPELNUql7kEpfIEHhw-1; Fri, 21 Oct 2022 11:35:57 -0400 X-MC-Unique: lnmOZPELNUql7kEpfIEHhw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 07F77803D49; Fri, 21 Oct 2022 15:35:57 +0000 (UTC) Received: from ovpn-192-65.brq.redhat.com (ovpn-192-65.brq.redhat.com [10.40.192.65]) by smtp.corp.redhat.com (Postfix) with ESMTP id F248D400EA8B; Fri, 21 Oct 2022 15:35:54 +0000 (UTC) From: Vitaly Kuznetsov To: kvm@vger.kernel.org, Paolo Bonzini , Sean Christopherson Cc: Wanpeng Li , Jim Mattson , Michael Kelley , Siddharth Chandrasekaran , Yuan Yao , Maxim Levitsky , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v12 12/46] KVM: x86: hyper-v: Expose support for extended gva ranges for flush hypercalls Date: Fri, 21 Oct 2022 17:34:47 +0200 Message-Id: <20221021153521.1216911-13-vkuznets@redhat.com> In-Reply-To: <20221021153521.1216911-1-vkuznets@redhat.com> References: <20221021153521.1216911-1-vkuznets@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747312234333654018?= X-GMAIL-MSGID: =?utf-8?q?1747312234333654018?= 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. Reviewed-by: Maxim Levitsky Signed-off-by: Vitaly Kuznetsov --- 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 c5e0e5a06c0d..6639979302ab 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 6868c478617c..fca9c51891f5 100644 --- a/arch/x86/kvm/hyperv.c +++ b/arch/x86/kvm/hyperv.c @@ -2641,6 +2641,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