From patchwork Tue Nov 1 14:53:50 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vitaly Kuznetsov X-Patchwork-Id: 13702 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp3020466wru; Tue, 1 Nov 2022 07:57:35 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7HDocwIs1uFFkl6XekwFu69fnZPC9T26HJqf2j2OdWuYCf5YWKG/UpkwumSqD+3TobILSz X-Received: by 2002:a17:907:2c47:b0:7a4:7673:d6ee with SMTP id hf7-20020a1709072c4700b007a47673d6eemr18985907ejc.397.1667314655610; Tue, 01 Nov 2022 07:57:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667314655; cv=none; d=google.com; s=arc-20160816; b=TRXKMS8UMHi0/L1kk5KH/uF35qWsCyvk0yfIdppFPkj/NNk+G72opDLmOBiYFRfzJZ BLMTaZqzJkbBG7kIRdkWxOFt20LEWhU2vDh1cVyKUx0NfuYdpdHM7z1T74/jxnoxAlRr RyiICOm3cxo/8kkoJzBwqjeN8StwanwoSFEFnn6oYMMXe2137T/Qfcd7dX/ZvtA005DR Xu7RFqpIYXL4/cywnSLyTXap1sNelqA82mBN/c6BQuPHT8sP3y76DtupMEgR5MJL5MsE BD6XteTRIfs97jkIQXEbXfLv74rSLKqnRAs1VuZs9yawpjkniep/n4/9amHVfMMn09Qe njag== 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=/Gaow8T3/Lj5DH5m6Ms44w/QXVfLY84K6VI7NN2LwuQ=; b=g7Jldq79zKkg5YCUWCQtYDTG863vb0j4Xt95nRBabCcDiH3XgYrq5RGjOhfZcizWMn WVxf785u1SagL1XbsOnPZOMaRGRNjB72y9Wjm/bGXG+yPpVpMneWBCsHJ2xFkUXghUJ6 BE6SMnUre/NCVathRpS+iXAgE8pk8jutHlDaaxeC7f9CnL81sQGUNb+V6asR4oNM0whQ dYE7v8sxiZS6TV3QCcICfDYIT8yT/0h2aGsYDsrae1O3utPrJX3WgahzcZNjBcccMJFf crxwQ/uKk+Uw830lyCpSNrypQYShCPSo9iAHXEe03vgVsukVAvCICVpMa/8eIUe4eosd Hr/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Mas8i25N; 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 y22-20020a056402359600b00459fc3fcf3csi13497072edc.102.2022.11.01.07.57.10; Tue, 01 Nov 2022 07:57:35 -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=Mas8i25N; 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 S231157AbiKAO4f (ORCPT + 99 others); Tue, 1 Nov 2022 10:56:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40344 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230493AbiKAO4J (ORCPT ); Tue, 1 Nov 2022 10:56:09 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3A2B63E7 for ; Tue, 1 Nov 2022 07:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667314508; 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=/Gaow8T3/Lj5DH5m6Ms44w/QXVfLY84K6VI7NN2LwuQ=; b=Mas8i25Na33A8ssw5RUxFk8Rbr7Jv1GYgztCrq9rN2EU0l+I88rWxw+i8lAtRRX0JnNRP/ treaLPQ8B0eIuJsZSCxZWdWAV2SKpkU9qADUrhyhiagpXlWqsEezV6iuFWE34NJeHzNX7r CX5zXv8y03IpFgG+JXLIMAI98GsuZL4= 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-575-bkWFKBtTPSOPJ2TrKqSEBA-1; Tue, 01 Nov 2022 10:55:03 -0400 X-MC-Unique: bkWFKBtTPSOPJ2TrKqSEBA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 071C18630CE; Tue, 1 Nov 2022 14:55:02 +0000 (UTC) Received: from ovpn-194-149.brq.redhat.com (ovpn-194-149.brq.redhat.com [10.40.194.149]) by smtp.corp.redhat.com (Postfix) with ESMTP id E5853C15BA5; Tue, 1 Nov 2022 14:54:59 +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 v13 12/48] KVM: x86: hyper-v: Expose support for extended gva ranges for flush hypercalls Date: Tue, 1 Nov 2022 15:53:50 +0100 Message-Id: <20221101145426.251680-13-vkuznets@redhat.com> In-Reply-To: <20221101145426.251680-1-vkuznets@redhat.com> References: <20221101145426.251680-1-vkuznets@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Spam-Status: No, score=-3.1 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?1748306132322792765?= X-GMAIL-MSGID: =?utf-8?q?1748306132322792765?= 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 Reviewed-by: Sean Christopherson 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