From nobody Thu May 9 08:42:32 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1653480414; cv=none; d=zohomail.com; s=zohoarc; b=dqoVl+gLg31/QbgvHJDLcvGdQz3CiSNr2KQWHr120shbdxGBRkyKDkgpVaVnnJ1pswNK2Nq0xxdIQzSDw68znvPQs13pbOX8FEhKVgoa7kUt2lo1tz0zHDDPhpi0czsdybECpkBhnJIL3mSG/Jq75zlrVZW5wvO5U09c5A2f2Yk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1653480414; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=L0c0wH8nVBZDZtXQVlhIFGXfDP6ZgqXZXbc7Chx12Ig=; b=k5Nwgdo4P00L3+r8hao0HXtEFfU7cm+9AoSZda7rN3sG2Wb4D2p9KkiBNsZo/T0qqCYWsB8niD0CE/cnz9olIc04ufI2pntHlM3+e90voOCbFYti5EuBdfiXPqWkVRZpTAhi0NAiJ+fVuz7k8RcrBLBfQ6kMHkaxGemmBkqPWTo= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1653480414867977.4110716213927; Wed, 25 May 2022 05:06:54 -0700 (PDT) Received: from localhost ([::1]:51986 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ntpmv-00084b-PV for importer@patchew.org; Wed, 25 May 2022 08:06:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35940) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntpgF-0004x5-G2 for qemu-devel@nongnu.org; Wed, 25 May 2022 07:59:59 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:58906) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntpgA-0000jP-TN for qemu-devel@nongnu.org; Wed, 25 May 2022 07:59:59 -0400 Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-52-72i1lOKbNWioCjX-tJ_4UQ-1; Wed, 25 May 2022 07:59:53 -0400 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 E22F01D3236B for ; Wed, 25 May 2022 11:59:52 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.40.194.186]) by smtp.corp.redhat.com (Postfix) with ESMTP id C89B940CFD0B; Wed, 25 May 2022 11:59:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1653479994; 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=L0c0wH8nVBZDZtXQVlhIFGXfDP6ZgqXZXbc7Chx12Ig=; b=Q4SJih3mrYzhMuCAPLkwyFzoDek/bE8zQAPdX+OFexNK6V+8RbYHPcWwtZxnzCOtOLlYt0 A5b6EMwQS18yDO83zBcK+Vqs+2iqUq7AjMjgNmRY1jTN5JNaac1BTporBXitswIVMPVknk TWi58dpzo7CeCbJ69im9xIgHhPBuXU8= X-MC-Unique: 72i1lOKbNWioCjX-tJ_4UQ-1 From: Vitaly Kuznetsov To: qemu-devel@nongnu.org, Paolo Bonzini Cc: Marcelo Tosatti Subject: [PATCH v4 1/6] i386: Use hv_build_cpuid_leaf() for HV_CPUID_NESTED_FEATURES Date: Wed, 25 May 2022 13:59:44 +0200 Message-Id: <20220525115949.1294004-2-vkuznets@redhat.com> In-Reply-To: <20220525115949.1294004-1-vkuznets@redhat.com> References: <20220525115949.1294004-1-vkuznets@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=170.10.133.124; envelope-from=vkuznets@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.082, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1653480415579100001 Content-Type: text/plain; charset="utf-8" Previously, HV_CPUID_NESTED_FEATURES.EAX CPUID leaf was handled differently as it was only used to encode the supported eVMCS version range. In fact, there are also feature (e.g. Enlightened MSR-Bitmap) bits there. In preparation to adding these features, move HV_CPUID_NESTED_FEATURES leaf handling to hv_build_cpuid_leaf() and drop now-unneeded 'hyperv_nested'. No functional change intended. Signed-off-by: Vitaly Kuznetsov --- target/i386/cpu.h | 1 - target/i386/kvm/kvm.c | 25 +++++++++++++++---------- 2 files changed, 15 insertions(+), 11 deletions(-) diff --git a/target/i386/cpu.h b/target/i386/cpu.h index 0d528ac58f32..2e918daf6bef 100644 --- a/target/i386/cpu.h +++ b/target/i386/cpu.h @@ -1804,7 +1804,6 @@ struct ArchCPU { uint32_t hyperv_vendor_id[3]; uint32_t hyperv_interface_id[4]; uint32_t hyperv_limits[3]; - uint32_t hyperv_nested[4]; bool hyperv_enforce_cpuid; uint32_t hyperv_ver_id_build; uint16_t hyperv_ver_id_major; diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c index a9ee8eebd76f..93bfefa4a79e 100644 --- a/target/i386/kvm/kvm.c +++ b/target/i386/kvm/kvm.c @@ -831,6 +831,8 @@ static bool tsc_is_stable_and_known(CPUX86State *env) || env->user_tsc_khz; } =20 +#define DEFAULT_EVMCS_VERSION ((1 << 8) | 1) + static struct { const char *desc; struct { @@ -1254,6 +1256,13 @@ static uint32_t hv_build_cpuid_leaf(CPUState *cs, ui= nt32_t func, int reg) } } =20 + /* HV_CPUID_NESTED_FEATURES.EAX also encodes the supported eVMCS range= */ + if (func =3D=3D HV_CPUID_NESTED_FEATURES && reg =3D=3D R_EAX) { + if (hyperv_feat_enabled(cpu, HYPERV_FEAT_EVMCS)) { + r |=3D DEFAULT_EVMCS_VERSION; + } + } + return r; } =20 @@ -1384,11 +1393,11 @@ static int hyperv_fill_cpuids(CPUState *cs, struct kvm_cpuid_entry2 *c; uint32_t signature[3]; uint32_t cpuid_i =3D 0, max_cpuid_leaf =3D 0; + uint32_t nested_eax =3D + hv_build_cpuid_leaf(cs, HV_CPUID_NESTED_FEATURES, R_EAX); =20 - max_cpuid_leaf =3D HV_CPUID_IMPLEMENT_LIMITS; - if (hyperv_feat_enabled(cpu, HYPERV_FEAT_EVMCS)) { - max_cpuid_leaf =3D MAX(max_cpuid_leaf, HV_CPUID_NESTED_FEATURES); - } + max_cpuid_leaf =3D nested_eax ? HV_CPUID_NESTED_FEATURES : + HV_CPUID_IMPLEMENT_LIMITS; =20 if (hyperv_feat_enabled(cpu, HYPERV_FEAT_SYNDBG)) { max_cpuid_leaf =3D @@ -1461,7 +1470,7 @@ static int hyperv_fill_cpuids(CPUState *cs, c->ecx =3D cpu->hyperv_limits[1]; c->edx =3D cpu->hyperv_limits[2]; =20 - if (hyperv_feat_enabled(cpu, HYPERV_FEAT_EVMCS)) { + if (nested_eax) { uint32_t function; =20 /* Create zeroed 0x40000006..0x40000009 leaves */ @@ -1473,7 +1482,7 @@ static int hyperv_fill_cpuids(CPUState *cs, =20 c =3D &cpuid_ent[cpuid_i++]; c->function =3D HV_CPUID_NESTED_FEATURES; - c->eax =3D cpu->hyperv_nested[0]; + c->eax =3D nested_eax; } =20 if (hyperv_feat_enabled(cpu, HYPERV_FEAT_SYNDBG)) { @@ -1522,8 +1531,6 @@ static bool evmcs_version_supported(uint16_t evmcs_ve= rsion, (max_version <=3D max_supported_version); } =20 -#define DEFAULT_EVMCS_VERSION ((1 << 8) | 1) - static int hyperv_init_vcpu(X86CPU *cpu) { CPUState *cs =3D CPU(cpu); @@ -1620,8 +1627,6 @@ static int hyperv_init_vcpu(X86CPU *cpu) supported_evmcs_version >> 8); return -ENOTSUP; } - - cpu->hyperv_nested[0] =3D evmcs_version; } =20 if (cpu->hyperv_enforce_cpuid) { --=20 2.35.3 From nobody Thu May 9 08:42:32 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1653480406; cv=none; d=zohomail.com; s=zohoarc; b=VD65LjP5ZXVywdRTbZWTKfMR2F5x0LwB7sqGb5a3hqKiF2voFcq3ii73GXzvTTyVo1xLIVzQVFCJ2NibjwKOGBK+Du72GrNa+6Llc6dTRK2jjJ6qCDISpskjmmbw7TCqOi82tMwybiZsfAQN1Es36eWUZbg6iLo6iE1RamiFHiE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1653480406; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=CiMvOyIxBm73NtAT8j9CPiFE0748/R4EBpiDYPB7Iks=; b=YCLzxLzaGzm4/9c194wpO1iSgQIOtcFfu4ghnUNO2picaALzgI8+gfYM/7Foi1FlyyW6fw2VSEm6WtQ7IyAYqsMLqOKdQFRKdYOf72ck+sSEAhwx6UAYg8x1mADaqeXCYOVbfYlSduqRmmNNdrOaHIg2N1jse9TT+ib0dgeCLEY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1653480406422849.2564088045809; Wed, 25 May 2022 05:06:46 -0700 (PDT) Received: from localhost ([::1]:51842 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ntpmn-0007yY-FM for importer@patchew.org; Wed, 25 May 2022 08:06:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35938) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntpgF-0004x4-BY for qemu-devel@nongnu.org; Wed, 25 May 2022 07:59:59 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:56517) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntpgD-0000ja-NL for qemu-devel@nongnu.org; Wed, 25 May 2022 07:59:59 -0400 Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-532-c1xGTiakP6GE9TgufFkYVg-1; Wed, 25 May 2022 07:59:54 -0400 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 7061729DD995 for ; Wed, 25 May 2022 11:59:54 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.40.194.186]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4D7C140CF8EF; Wed, 25 May 2022 11:59:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1653479995; 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=CiMvOyIxBm73NtAT8j9CPiFE0748/R4EBpiDYPB7Iks=; b=Tj/DgV3Mr38zlhr2q06C5OqCTc+kOUGNIyskxHJH9SK/VgNWuQy4fF63wEdBl+sZ+1mmjM RUjr8vJdI4cSPUj8gPBl5I5DFbJW3N/j3777+YtjH8E2iHdIPSWb1yNWfpVCt+AwcjTATc btUrZWRZhoXzmCzdEDOoDLSsO/pErRg= X-MC-Unique: c1xGTiakP6GE9TgufFkYVg-1 From: Vitaly Kuznetsov To: qemu-devel@nongnu.org, Paolo Bonzini Cc: Marcelo Tosatti Subject: [PATCH v4 2/6] i386: Hyper-V Enlightened MSR bitmap feature Date: Wed, 25 May 2022 13:59:45 +0200 Message-Id: <20220525115949.1294004-3-vkuznets@redhat.com> In-Reply-To: <20220525115949.1294004-1-vkuznets@redhat.com> References: <20220525115949.1294004-1-vkuznets@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=170.10.133.124; envelope-from=vkuznets@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.082, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1653480407605100001 Content-Type: text/plain; charset="utf-8" The newly introduced enlightenment allow L0 (KVM) and L1 (Hyper-V) hypervisors to collaborate to avoid unnecessary updates to L2 MSR-Bitmap upon vmexits. Signed-off-by: Vitaly Kuznetsov --- docs/hyperv.txt | 9 +++++++++ target/i386/cpu.c | 2 ++ target/i386/cpu.h | 1 + target/i386/kvm/hyperv-proto.h | 5 +++++ target/i386/kvm/kvm.c | 7 +++++++ 5 files changed, 24 insertions(+) diff --git a/docs/hyperv.txt b/docs/hyperv.txt index 33588a03961f..5d85569b9941 100644 --- a/docs/hyperv.txt +++ b/docs/hyperv.txt @@ -239,6 +239,15 @@ This enlightenment requires a VMBus device (-device vm= bus-bridge,irq=3D15) and the follow enlightenments to work: hv-relaxed,hv_time,hv-vapic,hv-vpindex,hv-synic,hv-runtime,hv-stimer =20 +3.22. hv-emsr-bitmap +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +The enlightenment is nested specific, it targets Hyper-V on KVM guests. Wh= en +enabled, it allows L0 (KVM) and L1 (Hyper-V) hypervisors to collaborate to +avoid unnecessary updates to L2 MSR-Bitmap upon vmexits. While the protoco= l is +supported for both VMX (Intel) and SVM (AMD), the VMX implementation requi= res +Enlightened VMCS ('hv-evmcs') feature to also be enabled. + +Recommended: hv-evmcs (Intel) =20 4. Supplementary features =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 35c3475e6c90..5aabf0c12e8d 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -6960,6 +6960,8 @@ static Property x86_cpu_properties[] =3D { HYPERV_FEAT_STIMER_DIRECT, 0), DEFINE_PROP_BIT64("hv-avic", X86CPU, hyperv_features, HYPERV_FEAT_AVIC, 0), + DEFINE_PROP_BIT64("hv-emsr-bitmap", X86CPU, hyperv_features, + HYPERV_FEAT_MSR_BITMAP, 0), DEFINE_PROP_ON_OFF_AUTO("hv-no-nonarch-coresharing", X86CPU, hyperv_no_nonarch_cs, ON_OFF_AUTO_OFF), DEFINE_PROP_BIT64("hv-syndbg", X86CPU, hyperv_features, diff --git a/target/i386/cpu.h b/target/i386/cpu.h index 2e918daf6bef..c7882857366d 100644 --- a/target/i386/cpu.h +++ b/target/i386/cpu.h @@ -1106,6 +1106,7 @@ uint64_t x86_cpu_get_supported_feature_word(FeatureWo= rd w, #define HYPERV_FEAT_STIMER_DIRECT 14 #define HYPERV_FEAT_AVIC 15 #define HYPERV_FEAT_SYNDBG 16 +#define HYPERV_FEAT_MSR_BITMAP 17 =20 #ifndef HYPERV_SPINLOCK_NEVER_NOTIFY #define HYPERV_SPINLOCK_NEVER_NOTIFY 0xFFFFFFFF diff --git a/target/i386/kvm/hyperv-proto.h b/target/i386/kvm/hyperv-proto.h index e40e59411c83..cea18dbc0e23 100644 --- a/target/i386/kvm/hyperv-proto.h +++ b/target/i386/kvm/hyperv-proto.h @@ -86,6 +86,11 @@ */ #define HV_SYNDBG_CAP_ALLOW_KERNEL_DEBUGGING (1u << 1) =20 +/* + * HV_CPUID_NESTED_FEATURES.EAX bits + */ +#define HV_NESTED_MSR_BITMAP (1u << 19) + /* * Basic virtualized MSRs */ diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c index 93bfefa4a79e..82d1f0275c42 100644 --- a/target/i386/kvm/kvm.c +++ b/target/i386/kvm/kvm.c @@ -973,6 +973,13 @@ static struct { .dependencies =3D BIT(HYPERV_FEAT_SYNIC) | BIT(HYPERV_FEAT_RELAXED) }, #endif + [HYPERV_FEAT_MSR_BITMAP] =3D { + .desc =3D "enlightened MSR-Bitmap (hv-emsr-bitmap)", + .flags =3D { + {.func =3D HV_CPUID_NESTED_FEATURES, .reg =3D R_EAX, + .bits =3D HV_NESTED_MSR_BITMAP} + } + }, }; =20 static struct kvm_cpuid2 *try_get_hv_cpuid(CPUState *cs, int max, --=20 2.35.3 From nobody Thu May 9 08:42:32 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1653480730; cv=none; d=zohomail.com; s=zohoarc; b=lE48T3xY/mivLv2JtytfSD6NMFCzD8mkGKX4RtuA/B6FOVfrvspXiFAni4WV6QEmF1nVolyANtdbKHGuiCShocWcMMK6eANSZ2BE1TjisPSYsPA6BMedhlN0kX9fZ37VlEVM9ffU/8IpcWHgGSaBznUm5HGKpVU2VTQqar+5Hoo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1653480730; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=PBmk8xyMqqwJp4XxYZwJs9QxzTTw8WlaS0a/s3B2Brk=; b=mL9CZ1x8iMXrAFgUS96zAVLXgIHC/U+YN88RTmiE7rvlXPfNoh73sb4SMcjHoLTrDkqzUP+AAO7+pcHNrAoCvHbhdSs2esurDxZkdMe92YlaTqv+Mg89sPkx7JUhZCJQwaHLPF49f2i02STf8VWSxoMoxYIuI3LER7S/f7weVMM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1653480730750444.4079299973322; Wed, 25 May 2022 05:12:10 -0700 (PDT) Received: from localhost ([::1]:60536 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ntps0-0007CG-Vk for importer@patchew.org; Wed, 25 May 2022 08:12:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35960) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntpgJ-0004z4-DP for qemu-devel@nongnu.org; Wed, 25 May 2022 08:00:03 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:48408) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntpgD-0000ji-VT for qemu-devel@nongnu.org; Wed, 25 May 2022 08:00:01 -0400 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-593-Ns5k5mmNMj-5Yoz49NUPyg-1; Wed, 25 May 2022 07:59:56 -0400 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 F316B858EED for ; Wed, 25 May 2022 11:59:55 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.40.194.186]) by smtp.corp.redhat.com (Postfix) with ESMTP id D0845400DB3A; Wed, 25 May 2022 11:59:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1653479997; 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=PBmk8xyMqqwJp4XxYZwJs9QxzTTw8WlaS0a/s3B2Brk=; b=HMr2LjQMi0ynv9fCMHH/gFqUvan5fT19gOruXilPqC+k2WbQ4dxigee5jshADUJUB89FV7 +VuOmWl+RwfVKEFSRvdGiBI8wOj7GTajbyGit8vD2BSo3dkpIH+WAn0//ybHMpQXtCpouT 1dblwylN8QLz9eediTV5VB85/gaDnOQ= X-MC-Unique: Ns5k5mmNMj-5Yoz49NUPyg-1 From: Vitaly Kuznetsov To: qemu-devel@nongnu.org, Paolo Bonzini Cc: Marcelo Tosatti Subject: [PATCH v4 3/6] i386: Hyper-V XMM fast hypercall input feature Date: Wed, 25 May 2022 13:59:46 +0200 Message-Id: <20220525115949.1294004-4-vkuznets@redhat.com> In-Reply-To: <20220525115949.1294004-1-vkuznets@redhat.com> References: <20220525115949.1294004-1-vkuznets@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=170.10.129.124; envelope-from=vkuznets@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.082, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1653480732642100001 Content-Type: text/plain; charset="utf-8" Hyper-V specification allows to pass parameters for certain hypercalls using XMM registers ("XMM Fast Hypercall Input"). When the feature is in use, it allows for faster hypercalls processing as KVM can avoid reading guest's memory. KVM supports the feature since v5.14. Rename HV_HYPERCALL_{PARAMS_XMM_AVAILABLE -> XMM_INPUT_AVAILABLE} to comply with KVM. Signed-off-by: Vitaly Kuznetsov --- docs/hyperv.txt | 6 ++++++ target/i386/cpu.c | 2 ++ target/i386/cpu.h | 1 + target/i386/kvm/hyperv-proto.h | 2 +- target/i386/kvm/kvm.c | 7 +++++++ 5 files changed, 17 insertions(+), 1 deletion(-) diff --git a/docs/hyperv.txt b/docs/hyperv.txt index 5d85569b9941..af1b10c0b3d1 100644 --- a/docs/hyperv.txt +++ b/docs/hyperv.txt @@ -249,6 +249,12 @@ Enlightened VMCS ('hv-evmcs') feature to also be enabl= ed. =20 Recommended: hv-evmcs (Intel) =20 +3.23. hv-xmm-input +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Hyper-V specification allows to pass parameters for certain hypercalls usi= ng XMM +registers ("XMM Fast Hypercall Input"). When the feature is in use, it all= ows +for faster hypercalls processing as KVM can avoid reading guest's memory. + 4. Supplementary features =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D =20 diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 5aabf0c12e8d..cb86c11f71d4 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -6962,6 +6962,8 @@ static Property x86_cpu_properties[] =3D { HYPERV_FEAT_AVIC, 0), DEFINE_PROP_BIT64("hv-emsr-bitmap", X86CPU, hyperv_features, HYPERV_FEAT_MSR_BITMAP, 0), + DEFINE_PROP_BIT64("hv-xmm-input", X86CPU, hyperv_features, + HYPERV_FEAT_XMM_INPUT, 0), DEFINE_PROP_ON_OFF_AUTO("hv-no-nonarch-coresharing", X86CPU, hyperv_no_nonarch_cs, ON_OFF_AUTO_OFF), DEFINE_PROP_BIT64("hv-syndbg", X86CPU, hyperv_features, diff --git a/target/i386/cpu.h b/target/i386/cpu.h index c7882857366d..37e95535843b 100644 --- a/target/i386/cpu.h +++ b/target/i386/cpu.h @@ -1107,6 +1107,7 @@ uint64_t x86_cpu_get_supported_feature_word(FeatureWo= rd w, #define HYPERV_FEAT_AVIC 15 #define HYPERV_FEAT_SYNDBG 16 #define HYPERV_FEAT_MSR_BITMAP 17 +#define HYPERV_FEAT_XMM_INPUT 18 =20 #ifndef HYPERV_SPINLOCK_NEVER_NOTIFY #define HYPERV_SPINLOCK_NEVER_NOTIFY 0xFFFFFFFF diff --git a/target/i386/kvm/hyperv-proto.h b/target/i386/kvm/hyperv-proto.h index cea18dbc0e23..f5f16474fa25 100644 --- a/target/i386/kvm/hyperv-proto.h +++ b/target/i386/kvm/hyperv-proto.h @@ -54,7 +54,7 @@ #define HV_GUEST_DEBUGGING_AVAILABLE (1u << 1) #define HV_PERF_MONITOR_AVAILABLE (1u << 2) #define HV_CPU_DYNAMIC_PARTITIONING_AVAILABLE (1u << 3) -#define HV_HYPERCALL_PARAMS_XMM_AVAILABLE (1u << 4) +#define HV_HYPERCALL_XMM_INPUT_AVAILABLE (1u << 4) #define HV_GUEST_IDLE_STATE_AVAILABLE (1u << 5) #define HV_FREQUENCY_MSRS_AVAILABLE (1u << 8) #define HV_GUEST_CRASH_MSR_AVAILABLE (1u << 10) diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c index 82d1f0275c42..96d6c50ad5d9 100644 --- a/target/i386/kvm/kvm.c +++ b/target/i386/kvm/kvm.c @@ -980,6 +980,13 @@ static struct { .bits =3D HV_NESTED_MSR_BITMAP} } }, + [HYPERV_FEAT_XMM_INPUT] =3D { + .desc =3D "XMM fast hypercall input (hv-xmm-input)", + .flags =3D { + {.func =3D HV_CPUID_FEATURES, .reg =3D R_EDX, + .bits =3D HV_HYPERCALL_XMM_INPUT_AVAILABLE} + } + }, }; =20 static struct kvm_cpuid2 *try_get_hv_cpuid(CPUState *cs, int max, --=20 2.35.3 From nobody Thu May 9 08:42:32 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1653480723; cv=none; d=zohomail.com; s=zohoarc; b=U8l1FoAR7Bg4MDwx9UbTR2mORaoYaUqjaA1lUyGQMOuWpuR+67Nwph92giCekZC6r91gZZlQMD2ydcPtwwVUJ+aGTEzjO/GHlmd0ht6wFIQ+j7asJRmUNTMWOUlucjkbUVw+35etIUFEDT7yVuaksdJ+u4MaocT82ZTAccb4D6o= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1653480723; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=2dqivw9mvMBBu11fC6hqiOvz7iZ/NUDFCtzB2JrxB5Q=; b=JA2JRqFohOhpV01ey3lOZp3oeQdy9elcWUBje2tHgU+6Lz+majXitaTFKgGhQJhVQDV18s0aU3Bh9f+zRg27guE7dto/FMbQldxPGq9M3a4VUQJUreE2yTgUpPbyGM/1j2QwiD/vFrN25428nukn7aDE9ONO2yPiux7D2+8osC4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1653480723884310.1120376864902; Wed, 25 May 2022 05:12:03 -0700 (PDT) Received: from localhost ([::1]:60238 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ntpru-0006tZ-QX for importer@patchew.org; Wed, 25 May 2022 08:12:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35974) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntpgL-00051E-0D for qemu-devel@nongnu.org; Wed, 25 May 2022 08:00:05 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:36783) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntpgI-0000jo-Vl for qemu-devel@nongnu.org; Wed, 25 May 2022 08:00:04 -0400 Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-370-dqi1terFMLyaJhi7GTP8nA-1; Wed, 25 May 2022 07:59:57 -0400 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 8C8AB1D3236A for ; Wed, 25 May 2022 11:59:57 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.40.194.186]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5F2B440CF8EF; Wed, 25 May 2022 11:59:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1653479999; 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=2dqivw9mvMBBu11fC6hqiOvz7iZ/NUDFCtzB2JrxB5Q=; b=VAfhyW3hMBfiEbkYegL1IDGrmAP/CR2GsL61QfSeuT8LPqrJaguOUuC+gLdt9lEq6Y5YJK olpZiS7mQyWrf+OrjW2Ly8HWx6wPvVJbqqkMfV4EY0J53e0AsDwH7qFwnZjFn26dqWStjo caUu8EYlHAjG2zyxcDy1jf54R7JL62k= X-MC-Unique: dqi1terFMLyaJhi7GTP8nA-1 From: Vitaly Kuznetsov To: qemu-devel@nongnu.org, Paolo Bonzini Cc: Marcelo Tosatti Subject: [PATCH v4 4/6] i386: Hyper-V Support extended GVA ranges for TLB flush hypercalls Date: Wed, 25 May 2022 13:59:47 +0200 Message-Id: <20220525115949.1294004-5-vkuznets@redhat.com> In-Reply-To: <20220525115949.1294004-1-vkuznets@redhat.com> References: <20220525115949.1294004-1-vkuznets@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=170.10.133.124; envelope-from=vkuznets@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.082, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1653480724864100001 Content-Type: text/plain; charset="utf-8" KVM kind of supported "extended GVA ranges" (up to 4095 additional GFNs per hypercall) since the implementation of Hyper-V PV TLB flush feature (Linux-4.18) as regardless of the request, full TLB flush was always performed. "Extended GVA ranges for TLB flush hypercalls" feature bit wasn't exposed then. Now, as KVM gains support for fine-grained TLB flush handling, exposing this feature starts making sense. Signed-off-by: Vitaly Kuznetsov --- docs/hyperv.txt | 7 +++++++ target/i386/cpu.c | 2 ++ target/i386/cpu.h | 1 + target/i386/kvm/hyperv-proto.h | 1 + target/i386/kvm/kvm.c | 8 ++++++++ 5 files changed, 19 insertions(+) diff --git a/docs/hyperv.txt b/docs/hyperv.txt index af1b10c0b3d1..4b132b1c941a 100644 --- a/docs/hyperv.txt +++ b/docs/hyperv.txt @@ -255,6 +255,13 @@ Hyper-V specification allows to pass parameters for ce= rtain hypercalls using XMM registers ("XMM Fast Hypercall Input"). When the feature is in use, it all= ows for faster hypercalls processing as KVM can avoid reading guest's memory. =20 +3.24. hv-tlbflush-ext +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Allow for extended GVA ranges to be passed to Hyper-V TLB flush hypercalls +(HvFlushVirtualAddressList/HvFlushVirtualAddressListEx). + +Requires: hv-tlbflush + 4. Supplementary features =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D =20 diff --git a/target/i386/cpu.c b/target/i386/cpu.c index cb86c11f71d4..a5331e6140fc 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -6964,6 +6964,8 @@ static Property x86_cpu_properties[] =3D { HYPERV_FEAT_MSR_BITMAP, 0), DEFINE_PROP_BIT64("hv-xmm-input", X86CPU, hyperv_features, HYPERV_FEAT_XMM_INPUT, 0), + DEFINE_PROP_BIT64("hv-tlbflush-ext", X86CPU, hyperv_features, + HYPERV_FEAT_TLBFLUSH_EXT, 0), DEFINE_PROP_ON_OFF_AUTO("hv-no-nonarch-coresharing", X86CPU, hyperv_no_nonarch_cs, ON_OFF_AUTO_OFF), DEFINE_PROP_BIT64("hv-syndbg", X86CPU, hyperv_features, diff --git a/target/i386/cpu.h b/target/i386/cpu.h index 37e95535843b..5ff48257e513 100644 --- a/target/i386/cpu.h +++ b/target/i386/cpu.h @@ -1108,6 +1108,7 @@ uint64_t x86_cpu_get_supported_feature_word(FeatureWo= rd w, #define HYPERV_FEAT_SYNDBG 16 #define HYPERV_FEAT_MSR_BITMAP 17 #define HYPERV_FEAT_XMM_INPUT 18 +#define HYPERV_FEAT_TLBFLUSH_EXT 19 =20 #ifndef HYPERV_SPINLOCK_NEVER_NOTIFY #define HYPERV_SPINLOCK_NEVER_NOTIFY 0xFFFFFFFF diff --git a/target/i386/kvm/hyperv-proto.h b/target/i386/kvm/hyperv-proto.h index f5f16474fa25..c7854ed6d306 100644 --- a/target/i386/kvm/hyperv-proto.h +++ b/target/i386/kvm/hyperv-proto.h @@ -59,6 +59,7 @@ #define HV_FREQUENCY_MSRS_AVAILABLE (1u << 8) #define HV_GUEST_CRASH_MSR_AVAILABLE (1u << 10) #define HV_FEATURE_DEBUG_MSRS_AVAILABLE (1u << 11) +#define HV_EXT_GVA_RANGES_FLUSH_AVAILABLE (1u << 14) #define HV_STIMER_DIRECT_MODE_AVAILABLE (1u << 19) =20 /* diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c index 96d6c50ad5d9..7bd1b4396e8e 100644 --- a/target/i386/kvm/kvm.c +++ b/target/i386/kvm/kvm.c @@ -987,6 +987,14 @@ static struct { .bits =3D HV_HYPERCALL_XMM_INPUT_AVAILABLE} } }, + [HYPERV_FEAT_TLBFLUSH_EXT] =3D { + .desc =3D "Extended gva ranges for TLB flush hypercalls (hv-tlbflu= sh-ext)", + .flags =3D { + {.func =3D HV_CPUID_FEATURES, .reg =3D R_EDX, + .bits =3D HV_EXT_GVA_RANGES_FLUSH_AVAILABLE} + }, + .dependencies =3D BIT(HYPERV_FEAT_TLBFLUSH) + }, }; =20 static struct kvm_cpuid2 *try_get_hv_cpuid(CPUState *cs, int max, --=20 2.35.3 From nobody Thu May 9 08:42:32 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1653480995; cv=none; d=zohomail.com; s=zohoarc; b=JDN0tU51pjaWmSEHuzmpyWfGB7MBlzcLfEwpO+rO07CNL3INd7P/0mNEYrFvVcGhm+MweBvloeLNbf9UIWOOHdc4M/DGb4/WrY0qscHObSziPKvZi/22zKbA+9SP40dEcPrs/CNclkTNiM9TKYBhQ3PFALO7xJLkZH0bMbyAb88= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1653480995; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=Ml1uEl1X5c8WJhxk/ne1a4iYO1dkt4sj+6xGGfjDmlw=; b=VanS/K81ZDQmMKKSyF/NQVdo/SqlTH7o+bVqLqbkh+DfHix06a6a5rdX59swbu/MjZD6ht9QlPsyt+o9eC7av9dTsz8pG2BT69XNFINDl5YyhHNMkGLQqnsh7DXtZPaU5v5b5Y5P7FQpyBArmlyRhzUYJnMPiw2IFH28YmAHcew= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1653480995046389.5585373302912; Wed, 25 May 2022 05:16:35 -0700 (PDT) Received: from localhost ([::1]:39240 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ntpwG-0003hV-3O for importer@patchew.org; Wed, 25 May 2022 08:16:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36028) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntpgR-00055o-NJ for qemu-devel@nongnu.org; Wed, 25 May 2022 08:00:13 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:39253) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntpgJ-0000k0-4F for qemu-devel@nongnu.org; Wed, 25 May 2022 08:00:11 -0400 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-490-tDRie9HsM8iX4jFuay8lzg-1; Wed, 25 May 2022 07:59:59 -0400 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 2F6C8811E75 for ; Wed, 25 May 2022 11:59:59 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.40.194.186]) by smtp.corp.redhat.com (Postfix) with ESMTP id E289540CF8EF; Wed, 25 May 2022 11:59:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1653480000; 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=Ml1uEl1X5c8WJhxk/ne1a4iYO1dkt4sj+6xGGfjDmlw=; b=CoknN84apO2RGhnT9NpvCvGybdtHJwfY9hgfQYKjvdoh6sONWQSfBhBgDiV/+5EDPhgmzu x551z1mzllKSY+tbEv9P3qRGKCUVPr2GwioJMBLCK1e8leI5cDmBsVoOoSqigRnFH2TeRt fxyCKHmugrLPYHOEqDoepF3p0Uh85Po= X-MC-Unique: tDRie9HsM8iX4jFuay8lzg-1 From: Vitaly Kuznetsov To: qemu-devel@nongnu.org, Paolo Bonzini Cc: Marcelo Tosatti Subject: [PATCH v4 5/6] i386: Hyper-V Direct TLB flush hypercall Date: Wed, 25 May 2022 13:59:48 +0200 Message-Id: <20220525115949.1294004-6-vkuznets@redhat.com> In-Reply-To: <20220525115949.1294004-1-vkuznets@redhat.com> References: <20220525115949.1294004-1-vkuznets@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=170.10.133.124; envelope-from=vkuznets@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.082, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1653480996657100001 Content-Type: text/plain; charset="utf-8" Hyper-V TLFS allows for L0 and L1 hypervisors to collaborate on L2's TLB flush hypercalls handling. With the correct setup, L2's TLB flush hypercalls can be handled by L0 directly, without the need to exit to L1. Signed-off-by: Vitaly Kuznetsov --- docs/hyperv.txt | 11 +++++++++++ target/i386/cpu.c | 2 ++ target/i386/cpu.h | 1 + target/i386/kvm/hyperv-proto.h | 1 + target/i386/kvm/kvm.c | 8 ++++++++ 5 files changed, 23 insertions(+) diff --git a/docs/hyperv.txt b/docs/hyperv.txt index 4b132b1c941a..14a7f449ead9 100644 --- a/docs/hyperv.txt +++ b/docs/hyperv.txt @@ -262,6 +262,17 @@ Allow for extended GVA ranges to be passed to Hyper-V = TLB flush hypercalls =20 Requires: hv-tlbflush =20 +3.25. hv-tlbflush-direct +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D +The enlightenment is nested specific, it targets Hyper-V on KVM guests. Wh= en +enabled, it allows L0 (KVM) to directly handle TLB flush hypercalls from L2 +guest without the need to exit to L1 (Hyper-V) hypervisor. While the featu= re is +supported for both VMX (Intel) and SVM (AMD), the VMX implementation requi= res +Enlightened VMCS ('hv-evmcs') feature to also be enabled. + +Requires: hv-vapic +Recommended: hv-evmcs (Intel) + 4. Supplementary features =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D =20 diff --git a/target/i386/cpu.c b/target/i386/cpu.c index a5331e6140fc..dfbf5a65f92f 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -6966,6 +6966,8 @@ static Property x86_cpu_properties[] =3D { HYPERV_FEAT_XMM_INPUT, 0), DEFINE_PROP_BIT64("hv-tlbflush-ext", X86CPU, hyperv_features, HYPERV_FEAT_TLBFLUSH_EXT, 0), + DEFINE_PROP_BIT64("hv-tlbflush-direct", X86CPU, hyperv_features, + HYPERV_FEAT_TLBFLUSH_DIRECT, 0), DEFINE_PROP_ON_OFF_AUTO("hv-no-nonarch-coresharing", X86CPU, hyperv_no_nonarch_cs, ON_OFF_AUTO_OFF), DEFINE_PROP_BIT64("hv-syndbg", X86CPU, hyperv_features, diff --git a/target/i386/cpu.h b/target/i386/cpu.h index 5ff48257e513..82004b65b944 100644 --- a/target/i386/cpu.h +++ b/target/i386/cpu.h @@ -1109,6 +1109,7 @@ uint64_t x86_cpu_get_supported_feature_word(FeatureWo= rd w, #define HYPERV_FEAT_MSR_BITMAP 17 #define HYPERV_FEAT_XMM_INPUT 18 #define HYPERV_FEAT_TLBFLUSH_EXT 19 +#define HYPERV_FEAT_TLBFLUSH_DIRECT 20 =20 #ifndef HYPERV_SPINLOCK_NEVER_NOTIFY #define HYPERV_SPINLOCK_NEVER_NOTIFY 0xFFFFFFFF diff --git a/target/i386/kvm/hyperv-proto.h b/target/i386/kvm/hyperv-proto.h index c7854ed6d306..464fbf09e35a 100644 --- a/target/i386/kvm/hyperv-proto.h +++ b/target/i386/kvm/hyperv-proto.h @@ -90,6 +90,7 @@ /* * HV_CPUID_NESTED_FEATURES.EAX bits */ +#define HV_NESTED_DIRECT_FLUSH (1u << 17) #define HV_NESTED_MSR_BITMAP (1u << 19) =20 /* diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c index 7bd1b4396e8e..8b58bfd0fd4a 100644 --- a/target/i386/kvm/kvm.c +++ b/target/i386/kvm/kvm.c @@ -995,6 +995,14 @@ static struct { }, .dependencies =3D BIT(HYPERV_FEAT_TLBFLUSH) }, + [HYPERV_FEAT_TLBFLUSH_DIRECT] =3D { + .desc =3D "direct TLB flush (hv-tlbflush-direct)", + .flags =3D { + {.func =3D HV_CPUID_NESTED_FEATURES, .reg =3D R_EAX, + .bits =3D HV_NESTED_DIRECT_FLUSH} + }, + .dependencies =3D BIT(HYPERV_FEAT_VAPIC) + }, }; =20 static struct kvm_cpuid2 *try_get_hv_cpuid(CPUState *cs, int max, --=20 2.35.3 From nobody Thu May 9 08:42:32 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1653481075; cv=none; d=zohomail.com; s=zohoarc; b=g3MQ/3OAJFemlXa0tlGQ21GShUjTjUhmlXtxIFMjpngQizTW3rrdprmEU2m5X0OANlKy7xIBmyRrysPBbpj3SFnjHw9SEDDMVPOi9KXTikfyW9cKnH1Nu0PHuwA80245Sn88zCpQ84fC++iw4TKYlPBDnnUNo5oX2Z4S7qJK3NY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1653481075; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=zNh2O/uAxlwjbg04LcBeW63ff/aky0mDwjCpoNAN3yk=; b=MvNeibvvZTs/8OlBKfaNPR4TUYQ+eo/mm5tNZxnQzRKh9RJL4341g5EXCcyMiEK0xZVF4HX6PLxxWB/d+fMtD4usDBd/6U5Mbl8JCr2vrg5kc286B4rzv0O8A1S1OFs6Yqt60QMvnNvRBU0eNcjozMEh/E7KtQyHb6KJcVgQryI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1653481075780945.9554999293081; Wed, 25 May 2022 05:17:55 -0700 (PDT) Received: from localhost ([::1]:41274 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ntpxa-0005HJ-KA for importer@patchew.org; Wed, 25 May 2022 08:17:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36072) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntpgd-00057t-Gj for qemu-devel@nongnu.org; Wed, 25 May 2022 08:00:40 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:60936) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntpgJ-0000l4-Aw for qemu-devel@nongnu.org; Wed, 25 May 2022 08:00:11 -0400 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-639-HvkdBo3hNyOcF59lzvctaw-1; Wed, 25 May 2022 08:00:01 -0400 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 DE4D9800B21 for ; Wed, 25 May 2022 12:00:00 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.40.194.186]) by smtp.corp.redhat.com (Postfix) with ESMTP id 70AEE40CF8EF; Wed, 25 May 2022 11:59:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1653480002; 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=zNh2O/uAxlwjbg04LcBeW63ff/aky0mDwjCpoNAN3yk=; b=CsuGDBYB2lWutLIpzh/vfXmwe/tQYTJRaek4ZpTCF0uCs7jkxUkuUcTBBPV6pxpFedg9h1 UWzrqE+VR7KK1C7yLRL2pjbZukGyWYrALP19w6Ke7upUVCzVyvIr4HN+KQys/CrUmyCGwi uocr7Mc+2oL+q5nD0dC3Hf07rdVuP+k= X-MC-Unique: HvkdBo3hNyOcF59lzvctaw-1 From: Vitaly Kuznetsov To: qemu-devel@nongnu.org, Paolo Bonzini Cc: Marcelo Tosatti Subject: [PATCH v4 6/6] i386: docs: Convert hyperv.txt to rST Date: Wed, 25 May 2022 13:59:49 +0200 Message-Id: <20220525115949.1294004-7-vkuznets@redhat.com> In-Reply-To: <20220525115949.1294004-1-vkuznets@redhat.com> References: <20220525115949.1294004-1-vkuznets@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=170.10.129.124; envelope-from=vkuznets@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.082, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1653481077156100001 Content-Type: text/plain; charset="utf-8" rSTify docs/hyperv.txt and link it from docs/system/target-i386.rst. Signed-off-by: Vitaly Kuznetsov --- docs/hyperv.txt | 303 ------------------------------------ docs/system/i386/hyperv.rst | 288 ++++++++++++++++++++++++++++++++++ docs/system/target-i386.rst | 1 + 3 files changed, 289 insertions(+), 303 deletions(-) delete mode 100644 docs/hyperv.txt create mode 100644 docs/system/i386/hyperv.rst diff --git a/docs/hyperv.txt b/docs/hyperv.txt deleted file mode 100644 index 14a7f449ead9..000000000000 --- a/docs/hyperv.txt +++ /dev/null @@ -1,303 +0,0 @@ -Hyper-V Enlightenments -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - - -1. Description -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -In some cases when implementing a hardware interface in software is slow, = KVM -implements its own paravirtualized interfaces. This works well for Linux as -guest support for such features is added simultaneously with the feature i= tself. -It may, however, be hard-to-impossible to add support for these interfaces= to -proprietary OSes, namely, Microsoft Windows. - -KVM on x86 implements Hyper-V Enlightenments for Windows guests. These fea= tures -make Windows and Hyper-V guests think they're running on top of a Hyper-V -compatible hypervisor and use Hyper-V specific features. - - -2. Setup -=3D=3D=3D=3D=3D=3D=3D=3D=3D -No Hyper-V enlightenments are enabled by default by either KVM or QEMU. In -QEMU, individual enlightenments can be enabled through CPU flags, e.g: - - qemu-system-x86_64 --enable-kvm --cpu host,hv_relaxed,hv_vpindex,hv_time= , ... - -Sometimes there are dependencies between enlightenments, QEMU is supposed = to -check that the supplied configuration is sane. - -When any set of the Hyper-V enlightenments is enabled, QEMU changes hyperv= isor -identification (CPUID 0x40000000..0x4000000A) to Hyper-V. KVM identificati= on -and features are kept in leaves 0x40000100..0x40000101. - - -3. Existing enlightenments -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D - -3.1. hv-relaxed -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -This feature tells guest OS to disable watchdog timeouts as it is running = on a -hypervisor. It is known that some Windows versions will do this even when = they -see 'hypervisor' CPU flag. - -3.2. hv-vapic -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Provides so-called VP Assist page MSR to guest allowing it to work with AP= IC -more efficiently. In particular, this enlightenment allows paravirtualized -(exit-less) EOI processing. - -3.3. hv-spinlocks=3Dxxx -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Enables paravirtualized spinlocks. The parameter indicates how many times -spinlock acquisition should be attempted before indicating the situation t= o the -hypervisor. A special value 0xffffffff indicates "never notify". - -3.4. hv-vpindex -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Provides HV_X64_MSR_VP_INDEX (0x40000002) MSR to the guest which has Virtu= al -processor index information. This enlightenment makes sense in conjunction= with -hv-synic, hv-stimer and other enlightenments which require the guest to kn= ow its -Virtual Processor indices (e.g. when VP index needs to be passed in a -hypercall). - -3.5. hv-runtime -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Provides HV_X64_MSR_VP_RUNTIME (0x40000010) MSR to the guest. The MSR keep= s the -virtual processor run time in 100ns units. This gives guest operating syst= em an -idea of how much time was 'stolen' from it (when the virtual CPU was preem= pted -to perform some other work). - -3.6. hv-crash -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Provides HV_X64_MSR_CRASH_P0..HV_X64_MSR_CRASH_P5 (0x40000100..0x40000105)= and -HV_X64_MSR_CRASH_CTL (0x40000105) MSRs to the guest. These MSRs are writte= n to -by the guest when it crashes, HV_X64_MSR_CRASH_P0..HV_X64_MSR_CRASH_P5 MSRs -contain additional crash information. This information is outputted in QEM= U log -and through QAPI. -Note: unlike under genuine Hyper-V, write to HV_X64_MSR_CRASH_CTL causes g= uest -to shutdown. This effectively blocks crash dump generation by Windows. - -3.7. hv-time -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Enables two Hyper-V-specific clocksources available to the guest: MSR-based -Hyper-V clocksource (HV_X64_MSR_TIME_REF_COUNT, 0x40000020) and Reference = TSC -page (enabled via MSR HV_X64_MSR_REFERENCE_TSC, 0x40000021). Both clocksou= rces -are per-guest, Reference TSC page clocksource allows for exit-less time st= amp -readings. Using this enlightenment leads to significant speedup of all tim= estamp -related operations. - -3.8. hv-synic -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Enables Hyper-V Synthetic interrupt controller - an extension of a local A= PIC. -When enabled, this enlightenment provides additional communication facilit= ies -to the guest: SynIC messages and Events. This is a pre-requisite for -implementing VMBus devices (not yet in QEMU). Additionally, this enlighten= ment -is needed to enable Hyper-V synthetic timers. SynIC is controlled through = MSRs -HV_X64_MSR_SCONTROL..HV_X64_MSR_EOM (0x40000080..0x40000084) and -HV_X64_MSR_SINT0..HV_X64_MSR_SINT15 (0x40000090..0x4000009F) - -Requires: hv-vpindex - -3.9. hv-stimer -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Enables Hyper-V synthetic timers. There are four synthetic timers per virt= ual -CPU controlled through HV_X64_MSR_STIMER0_CONFIG..HV_X64_MSR_STIMER3_COUNT -(0x400000B0..0x400000B7) MSRs. These timers can work either in single-shot= or -periodic mode. It is known that certain Windows versions revert to using H= PET -(or even RTC when HPET is unavailable) extensively when this enlightenment= is -not provided; this can lead to significant CPU consumption, even when virt= ual -CPU is idle. - -Requires: hv-vpindex, hv-synic, hv-time - -3.10. hv-tlbflush -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Enables paravirtualized TLB shoot-down mechanism. On x86 architecture, rem= ote -TLB flush procedure requires sending IPIs and waiting for other CPUs to pe= rform -local TLB flush. In virtualized environment some virtual CPUs may not even= be -scheduled at the time of the call and may not require flushing (or, flushi= ng -may be postponed until the virtual CPU is scheduled). hv-tlbflush enlighte= nment -implements TLB shoot-down through hypervisor enabling the optimization. - -Requires: hv-vpindex - -3.11. hv-ipi -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Enables paravirtualized IPI send mechanism. HvCallSendSyntheticClusterIpi -hypercall may target more than 64 virtual CPUs simultaneously, doing the s= ame -through APIC requires more than one access (and thus exit to the hyperviso= r). - -Requires: hv-vpindex - -3.12. hv-vendor-id=3Dxxx -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -This changes Hyper-V identification in CPUID 0x40000000.EBX-EDX from the d= efault -"Microsoft Hv". The parameter should be no longer than 12 characters. Acco= rding -to the specification, guests shouldn't use this information and it is unkn= own -if there is a Windows version which acts differently. -Note: hv-vendor-id is not an enlightenment and thus doesn't enable Hyper-V -identification when specified without some other enlightenment. - -3.13. hv-reset -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Provides HV_X64_MSR_RESET (0x40000003) MSR to the guest allowing it to res= et -itself by writing to it. Even when this MSR is enabled, it is not a recomm= ended -way for Windows to perform system reboot and thus it may not be used. - -3.14. hv-frequencies -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Provides HV_X64_MSR_TSC_FREQUENCY (0x40000022) and HV_X64_MSR_APIC_FREQUEN= CY -(0x40000023) allowing the guest to get its TSC/APIC frequencies without do= ing -measurements. - -3.15 hv-reenlightenment -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -The enlightenment is nested specific, it targets Hyper-V on KVM guests. Wh= en -enabled, it provides HV_X64_MSR_REENLIGHTENMENT_CONTROL (0x40000106), -HV_X64_MSR_TSC_EMULATION_CONTROL (0x40000107)and HV_X64_MSR_TSC_EMULATION_= STATUS -(0x40000108) MSRs allowing the guest to get notified when TSC frequency ch= anges -(only happens on migration) and keep using old frequency (through emulatio= n in -the hypervisor) until it is ready to switch to the new one. This, in conju= nction -with hv-frequencies, allows Hyper-V on KVM to pass stable clocksource (Ref= erence -TSC page) to its own guests. - -Note, KVM doesn't fully support re-enlightenment notifications and doesn't -emulate TSC accesses after migration so 'tsc-frequency=3D' CPU option also= has to -be specified to make migration succeed. The destination host has to either= have -the same TSC frequency or support TSC scaling CPU feature. - -Recommended: hv-frequencies - -3.16. hv-evmcs -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -The enlightenment is nested specific, it targets Hyper-V on KVM guests. Wh= en -enabled, it provides Enlightened VMCS version 1 feature to the guest. The = feature -implements paravirtualized protocol between L0 (KVM) and L1 (Hyper-V) -hypervisors making L2 exits to the hypervisor faster. The feature is Intel= -only. -Note: some virtualization features (e.g. Posted Interrupts) are disabled w= hen -hv-evmcs is enabled. It may make sense to measure your nested workload wit= h and -without the feature to find out if enabling it is beneficial. - -Requires: hv-vapic - -3.17. hv-stimer-direct -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Hyper-V specification allows synthetic timer operation in two modes: "clas= sic", -when expiration event is delivered as SynIC message and "direct", when the= event -is delivered via normal interrupt. It is known that nested Hyper-V can only -use synthetic timers in direct mode and thus 'hv-stimer-direct' needs to be -enabled. - -Requires: hv-vpindex, hv-synic, hv-time, hv-stimer - -3.18. hv-avic (hv-apicv) -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -The enlightenment allows to use Hyper-V SynIC with hardware APICv/AVIC ena= bled. -Normally, Hyper-V SynIC disables these hardware feature and suggests the g= uest -to use paravirtualized AutoEOI feature. -Note: enabling this feature on old hardware (without APICv/AVIC support) m= ay -have negative effect on guest's performance. - -3.19. hv-no-nonarch-coresharing=3Don/off/auto -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -This enlightenment tells guest OS that virtual processors will never share= a -physical core unless they are reported as sibling SMT threads. This inform= ation -is required by Windows and Hyper-V guests to properly mitigate SMT related= CPU -vulnerabilities. -When the option is set to 'auto' QEMU will enable the feature only when KVM -reports that non-architectural coresharing is impossible, this means that -hyper-threading is not supported or completely disabled on the host. This -setting also prevents migration as SMT settings on the destination may dif= fer. -When the option is set to 'on' QEMU will always enable the feature, regard= less -of host setup. To keep guests secure, this can only be used in conjunction= with -exposing correct vCPU topology and vCPU pinning. - -3.20. hv-version-id-{build,major,minor,spack,sbranch,snumber} -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -This changes Hyper-V version identification in CPUID 0x40000002.EAX-EDX fr= om the -default (WS2016). -- hv-version-id-build sets 'Build Number' (32 bits) -- hv-version-id-major sets 'Major Version' (16 bits) -- hv-version-id-minor sets 'Minor Version' (16 bits) -- hv-version-id-spack sets 'Service Pack' (32 bits) -- hv-version-id-sbranch sets 'Service Branch' (8 bits) -- hv-version-id-snumber sets 'Service Number' (24 bits) - -Note: hv-version-id-* are not enlightenments and thus don't enable Hyper-V -identification when specified without any other enlightenments. - -3.21. hv-syndbg -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Enables Hyper-V synthetic debugger interface, this is a special interface = used -by Windows Kernel debugger to send the packets through, rather than sending -them via serial/network . -When enabled, this enlightenment provides additional communication facilit= ies -to the guest: SynDbg messages. -This new communication is used by Windows Kernel debugger rather than send= ing -packets via serial/network, adding significant performance boost over the = other -comm channels. -This enlightenment requires a VMBus device (-device vmbus-bridge,irq=3D15) -and the follow enlightenments to work: -hv-relaxed,hv_time,hv-vapic,hv-vpindex,hv-synic,hv-runtime,hv-stimer - -3.22. hv-emsr-bitmap -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -The enlightenment is nested specific, it targets Hyper-V on KVM guests. Wh= en -enabled, it allows L0 (KVM) and L1 (Hyper-V) hypervisors to collaborate to -avoid unnecessary updates to L2 MSR-Bitmap upon vmexits. While the protoco= l is -supported for both VMX (Intel) and SVM (AMD), the VMX implementation requi= res -Enlightened VMCS ('hv-evmcs') feature to also be enabled. - -Recommended: hv-evmcs (Intel) - -3.23. hv-xmm-input -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Hyper-V specification allows to pass parameters for certain hypercalls usi= ng XMM -registers ("XMM Fast Hypercall Input"). When the feature is in use, it all= ows -for faster hypercalls processing as KVM can avoid reading guest's memory. - -3.24. hv-tlbflush-ext -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Allow for extended GVA ranges to be passed to Hyper-V TLB flush hypercalls -(HvFlushVirtualAddressList/HvFlushVirtualAddressListEx). - -Requires: hv-tlbflush - -3.25. hv-tlbflush-direct -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D -The enlightenment is nested specific, it targets Hyper-V on KVM guests. Wh= en -enabled, it allows L0 (KVM) to directly handle TLB flush hypercalls from L2 -guest without the need to exit to L1 (Hyper-V) hypervisor. While the featu= re is -supported for both VMX (Intel) and SVM (AMD), the VMX implementation requi= res -Enlightened VMCS ('hv-evmcs') feature to also be enabled. - -Requires: hv-vapic -Recommended: hv-evmcs (Intel) - -4. Supplementary features -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D - -4.1. hv-passthrough -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -In some cases (e.g. during development) it may make sense to use QEMU in -'pass-through' mode and give Windows guests all enlightenments currently -supported by KVM. This pass-through mode is enabled by "hv-passthrough" CPU -flag. -Note: "hv-passthrough" flag only enables enlightenments which are known to= QEMU -(have corresponding "hv-*" flag) and copies "hv-spinlocks=3D"/"hv-vendor-i= d=3D" -values from KVM to QEMU. "hv-passthrough" overrides all other "hv-*" setti= ngs on -the command line. Also, enabling this flag effectively prevents migration = as the -list of enabled enlightenments may differ between target and destination h= osts. - -4.2. hv-enforce-cpuid -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -By default, KVM allows the guest to use all currently supported Hyper-V -enlightenments when Hyper-V CPUID interface was exposed, regardless of if -some features were not announced in guest visible CPUIDs. 'hv-enforce-cpui= d' -feature alters this behavior and only allows the guest to use exposed Hype= r-V -enlightenments. - - -5. Useful links -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Hyper-V Top Level Functional specification and other information: -https://github.com/MicrosoftDocs/Virtualization-Documentation diff --git a/docs/system/i386/hyperv.rst b/docs/system/i386/hyperv.rst new file mode 100644 index 000000000000..2505dc4c86e0 --- /dev/null +++ b/docs/system/i386/hyperv.rst @@ -0,0 +1,288 @@ +Hyper-V Enlightenments +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + + +Description +----------- + +In some cases when implementing a hardware interface in software is slow, = KVM +implements its own paravirtualized interfaces. This works well for Linux as +guest support for such features is added simultaneously with the feature i= tself. +It may, however, be hard-to-impossible to add support for these interfaces= to +proprietary OSes, namely, Microsoft Windows. + +KVM on x86 implements Hyper-V Enlightenments for Windows guests. These fea= tures +make Windows and Hyper-V guests think they're running on top of a Hyper-V +compatible hypervisor and use Hyper-V specific features. + + +Setup +----- + +No Hyper-V enlightenments are enabled by default by either KVM or QEMU. In +QEMU, individual enlightenments can be enabled through CPU flags, e.g: + +.. parsed-literal:: + + |qemu_system| --enable-kvm --cpu host,hv_relaxed,hv_vpindex,hv_time, ... + +Sometimes there are dependencies between enlightenments, QEMU is supposed = to +check that the supplied configuration is sane. + +When any set of the Hyper-V enlightenments is enabled, QEMU changes hyperv= isor +identification (CPUID 0x40000000..0x4000000A) to Hyper-V. KVM identificati= on +and features are kept in leaves 0x40000100..0x40000101. + + +Existing enlightenments +----------------------- + +``hv-relaxed`` + This feature tells guest OS to disable watchdog timeouts as it is runnin= g on a + hypervisor. It is known that some Windows versions will do this even whe= n they + see 'hypervisor' CPU flag. + +``hv-vapic`` + Provides so-called VP Assist page MSR to guest allowing it to work with = APIC + more efficiently. In particular, this enlightenment allows paravirtualiz= ed + (exit-less) EOI processing. + +``hv-spinlocks`` =3D xxx + Enables paravirtualized spinlocks. The parameter indicates how many times + spinlock acquisition should be attempted before indicating the situation= to the + hypervisor. A special value 0xffffffff indicates "never notify". + +``hv-vpindex`` + Provides HV_X64_MSR_VP_INDEX (0x40000002) MSR to the guest which has Vir= tual + processor index information. This enlightenment makes sense in conjuncti= on with + hv-synic, hv-stimer and other enlightenments which require the guest to = know its + Virtual Processor indices (e.g. when VP index needs to be passed in a + hypercall). + +``hv-runtime`` + Provides HV_X64_MSR_VP_RUNTIME (0x40000010) MSR to the guest. The MSR ke= eps the + virtual processor run time in 100ns units. This gives guest operating sy= stem an + idea of how much time was 'stolen' from it (when the virtual CPU was pre= empted + to perform some other work). + +``hv-crash`` + Provides HV_X64_MSR_CRASH_P0..HV_X64_MSR_CRASH_P5 (0x40000100..0x4000010= 5) and + HV_X64_MSR_CRASH_CTL (0x40000105) MSRs to the guest. These MSRs are writ= ten to + by the guest when it crashes, HV_X64_MSR_CRASH_P0..HV_X64_MSR_CRASH_P5 M= SRs + contain additional crash information. This information is outputted in Q= EMU log + and through QAPI. + Note: unlike under genuine Hyper-V, write to HV_X64_MSR_CRASH_CTL causes= guest + to shutdown. This effectively blocks crash dump generation by Windows. + +``hv-time`` + Enables two Hyper-V-specific clocksources available to the guest: MSR-ba= sed + Hyper-V clocksource (HV_X64_MSR_TIME_REF_COUNT, 0x40000020) and Referenc= e TSC + page (enabled via MSR HV_X64_MSR_REFERENCE_TSC, 0x40000021). Both clocks= ources + are per-guest, Reference TSC page clocksource allows for exit-less time = stamp + readings. Using this enlightenment leads to significant speedup of all t= imestamp + related operations. + +``hv-synic`` + Enables Hyper-V Synthetic interrupt controller - an extension of a local= APIC. + When enabled, this enlightenment provides additional communication facil= ities + to the guest: SynIC messages and Events. This is a pre-requisite for + implementing VMBus devices (not yet in QEMU). Additionally, this enlight= enment + is needed to enable Hyper-V synthetic timers. SynIC is controlled throug= h MSRs + HV_X64_MSR_SCONTROL..HV_X64_MSR_EOM (0x40000080..0x40000084) and + HV_X64_MSR_SINT0..HV_X64_MSR_SINT15 (0x40000090..0x4000009F) + + Requires: ``hv-vpindex`` + +``hv-stimer`` + Enables Hyper-V synthetic timers. There are four synthetic timers per vi= rtual + CPU controlled through HV_X64_MSR_STIMER0_CONFIG..HV_X64_MSR_STIMER3_COU= NT + (0x400000B0..0x400000B7) MSRs. These timers can work either in single-sh= ot or + periodic mode. It is known that certain Windows versions revert to using= HPET + (or even RTC when HPET is unavailable) extensively when this enlightenme= nt is + not provided; this can lead to significant CPU consumption, even when vi= rtual + CPU is idle. + + Requires: ``hv-vpindex``, ``hv-synic``, ``hv-time`` + +``hv-tlbflush`` + Enables paravirtualized TLB shoot-down mechanism. On x86 architecture, r= emote + TLB flush procedure requires sending IPIs and waiting for other CPUs to = perform + local TLB flush. In virtualized environment some virtual CPUs may not ev= en be + scheduled at the time of the call and may not require flushing (or, flus= hing + may be postponed until the virtual CPU is scheduled). hv-tlbflush enligh= tenment + implements TLB shoot-down through hypervisor enabling the optimization. + + Requires: ``hv-vpindex`` + +``hv-ipi`` + Enables paravirtualized IPI send mechanism. HvCallSendSyntheticClusterIpi + hypercall may target more than 64 virtual CPUs simultaneously, doing the= same + through APIC requires more than one access (and thus exit to the hypervi= sor). + + Requires: ``hv-vpindex`` + +``hv-vendor-id`` =3D xxx + This changes Hyper-V identification in CPUID 0x40000000.EBX-EDX from the= default + "Microsoft Hv". The parameter should be no longer than 12 characters. Ac= cording + to the specification, guests shouldn't use this information and it is un= known + if there is a Windows version which acts differently. + Note: hv-vendor-id is not an enlightenment and thus doesn't enable Hyper= -V + identification when specified without some other enlightenment. + +``hv-reset`` + Provides HV_X64_MSR_RESET (0x40000003) MSR to the guest allowing it to r= eset + itself by writing to it. Even when this MSR is enabled, it is not a reco= mmended + way for Windows to perform system reboot and thus it may not be used. + +``hv-frequencies`` + Provides HV_X64_MSR_TSC_FREQUENCY (0x40000022) and HV_X64_MSR_APIC_FREQU= ENCY + (0x40000023) allowing the guest to get its TSC/APIC frequencies without = doing + measurements. + +``hv-reenlightenment`` + The enlightenment is nested specific, it targets Hyper-V on KVM guests. = When + enabled, it provides HV_X64_MSR_REENLIGHTENMENT_CONTROL (0x40000106), + HV_X64_MSR_TSC_EMULATION_CONTROL (0x40000107)and HV_X64_MSR_TSC_EMULATIO= N_STATUS + (0x40000108) MSRs allowing the guest to get notified when TSC frequency = changes + (only happens on migration) and keep using old frequency (through emulat= ion in + the hypervisor) until it is ready to switch to the new one. This, in con= junction + with ``hv-frequencies``, allows Hyper-V on KVM to pass stable clocksource + (Reference TSC page) to its own guests. + + Note, KVM doesn't fully support re-enlightenment notifications and doesn= 't + emulate TSC accesses after migration so 'tsc-frequency=3D' CPU option al= so has to + be specified to make migration succeed. The destination host has to eith= er have + the same TSC frequency or support TSC scaling CPU feature. + + Recommended: ``hv-frequencies`` + +``hv-evmcs`` + The enlightenment is nested specific, it targets Hyper-V on KVM guests. = When + enabled, it provides Enlightened VMCS version 1 feature to the guest. Th= e feature + implements paravirtualized protocol between L0 (KVM) and L1 (Hyper-V) + hypervisors making L2 exits to the hypervisor faster. The feature is Int= el-only. + + Note: some virtualization features (e.g. Posted Interrupts) are disabled= when + hv-evmcs is enabled. It may make sense to measure your nested workload w= ith and + without the feature to find out if enabling it is beneficial. + + Requires: ``hv-vapic`` + +``hv-stimer-direct`` + Hyper-V specification allows synthetic timer operation in two modes: "cl= assic", + when expiration event is delivered as SynIC message and "direct", when t= he event + is delivered via normal interrupt. It is known that nested Hyper-V can o= nly + use synthetic timers in direct mode and thus ``hv-stimer-direct`` needs = to be + enabled. + + Requires: ``hv-vpindex``, ``hv-synic``, ``hv-time``, ``hv-stimer`` + +``hv-avic`` (``hv-apicv``) + The enlightenment allows to use Hyper-V SynIC with hardware APICv/AVIC e= nabled. + Normally, Hyper-V SynIC disables these hardware feature and suggests the= guest + to use paravirtualized AutoEOI feature. + Note: enabling this feature on old hardware (without APICv/AVIC support)= may + have negative effect on guest's performance. + +``hv-no-nonarch-coresharing`` =3D on/off/auto + This enlightenment tells guest OS that virtual processors will never sha= re a + physical core unless they are reported as sibling SMT threads. This info= rmation + is required by Windows and Hyper-V guests to properly mitigate SMT relat= ed CPU + vulnerabilities. + + When the option is set to 'auto' QEMU will enable the feature only when = KVM + reports that non-architectural coresharing is impossible, this means that + hyper-threading is not supported or completely disabled on the host. This + setting also prevents migration as SMT settings on the destination may d= iffer. + When the option is set to 'on' QEMU will always enable the feature, rega= rdless + of host setup. To keep guests secure, this can only be used in conjuncti= on with + exposing correct vCPU topology and vCPU pinning. + +``hv-version-id-build``, ``hv-version-id-major``, ``hv-version-id-minor``,= ``hv-version-id-spack``, ``hv-version-id-sbranch``, ``hv-version-id-snumbe= r`` + This changes Hyper-V version identification in CPUID 0x40000002.EAX-EDX = from the + default (WS2016). + + - ``hv-version-id-build`` sets 'Build Number' (32 bits) + - ``hv-version-id-major`` sets 'Major Version' (16 bits) + - ``hv-version-id-minor`` sets 'Minor Version' (16 bits) + - ``hv-version-id-spack`` sets 'Service Pack' (32 bits) + - ``hv-version-id-sbranch`` sets 'Service Branch' (8 bits) + - ``hv-version-id-snumber`` sets 'Service Number' (24 bits) + + Note: hv-version-id-* are not enlightenments and thus don't enable Hyper= -V + identification when specified without any other enlightenments. + +``hv-syndbg`` + Enables Hyper-V synthetic debugger interface, this is a special interfac= e used + by Windows Kernel debugger to send the packets through, rather than send= ing + them via serial/network . + When enabled, this enlightenment provides additional communication facil= ities + to the guest: SynDbg messages. + This new communication is used by Windows Kernel debugger rather than se= nding + packets via serial/network, adding significant performance boost over th= e other + comm channels. + This enlightenment requires a VMBus device (-device vmbus-bridge,irq=3D1= 5). + + Requires: ``hv-relaxed``, ``hv_time``, ``hv-vapic``, ``hv-vpindex``, ``h= v-synic``, ``hv-runtime``, ``hv-stimer`` + +``hv-emsr-bitmap`` + The enlightenment is nested specific, it targets Hyper-V on KVM guests. = When + enabled, it allows L0 (KVM) and L1 (Hyper-V) hypervisors to collaborate = to + avoid unnecessary updates to L2 MSR-Bitmap upon vmexits. While the proto= col is + supported for both VMX (Intel) and SVM (AMD), the VMX implementation req= uires + Enlightened VMCS (``hv-evmcs``) feature to also be enabled. + + Recommended: ``hv-evmcs`` (Intel) + +``hv-xmm-input`` + Hyper-V specification allows to pass parameters for certain hypercalls u= sing XMM + registers ("XMM Fast Hypercall Input"). When the feature is in use, it a= llows + for faster hypercalls processing as KVM can avoid reading guest's memory. + +``hv-tlbflush-ext`` + Allow for extended GVA ranges to be passed to Hyper-V TLB flush hypercal= ls + (HvFlushVirtualAddressList/HvFlushVirtualAddressListEx). + + Requires: ``hv-tlbflush`` + +``hv-tlbflush-direct`` + The enlightenment is nested specific, it targets Hyper-V on KVM guests. = When + enabled, it allows L0 (KVM) to directly handle TLB flush hypercalls from= L2 + guest without the need to exit to L1 (Hyper-V) hypervisor. While the fea= ture is + supported for both VMX (Intel) and SVM (AMD), the VMX implementation req= uires + Enlightened VMCS (``hv-evmcs``) feature to also be enabled. + + Requires: ``hv-vapic`` + + Recommended: ``hv-evmcs`` (Intel) + +Supplementary features +---------------------- + +``hv-passthrough`` + In some cases (e.g. during development) it may make sense to use QEMU in + 'pass-through' mode and give Windows guests all enlightenments currently + supported by KVM. This pass-through mode is enabled by "hv-passthrough" = CPU + flag. + + Note: ``hv-passthrough`` flag only enables enlightenments which are know= n to QEMU + (have corresponding 'hv-' flag) and copies ``hv-spinlocks`` and ``hv-ven= dor-id`` + values from KVM to QEMU. ``hv-passthrough`` overrides all other 'hv-' se= ttings on + the command line. Also, enabling this flag effectively prevents migratio= n as the + list of enabled enlightenments may differ between target and destination= hosts. + +``hv-enforce-cpuid`` + By default, KVM allows the guest to use all currently supported Hyper-V + enlightenments when Hyper-V CPUID interface was exposed, regardless of if + some features were not announced in guest visible CPUIDs. ``hv-enforce-c= puid`` + feature alters this behavior and only allows the guest to use exposed Hy= per-V + enlightenments. + + +Useful links +------------ +Hyper-V Top Level Functional specification and other information: + +- https://github.com/MicrosoftDocs/Virtualization-Documentation +- https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/= tlfs + diff --git a/docs/system/target-i386.rst b/docs/system/target-i386.rst index 96bf54889a82..e64c0130772d 100644 --- a/docs/system/target-i386.rst +++ b/docs/system/target-i386.rst @@ -26,6 +26,7 @@ Architectural features :maxdepth: 1 =20 i386/cpu + i386/hyperv i386/kvm-pv i386/sgx i386/amd-memory-encryption --=20 2.35.3