1*9ad6634eSVitaly KuznetsovHyper-V Enlightenments 2*9ad6634eSVitaly Kuznetsov====================== 3*9ad6634eSVitaly Kuznetsov 4*9ad6634eSVitaly Kuznetsov 5*9ad6634eSVitaly KuznetsovDescription 6*9ad6634eSVitaly Kuznetsov----------- 7*9ad6634eSVitaly Kuznetsov 8*9ad6634eSVitaly KuznetsovIn some cases when implementing a hardware interface in software is slow, KVM 9*9ad6634eSVitaly Kuznetsovimplements its own paravirtualized interfaces. This works well for Linux as 10*9ad6634eSVitaly Kuznetsovguest support for such features is added simultaneously with the feature itself. 11*9ad6634eSVitaly KuznetsovIt may, however, be hard-to-impossible to add support for these interfaces to 12*9ad6634eSVitaly Kuznetsovproprietary OSes, namely, Microsoft Windows. 13*9ad6634eSVitaly Kuznetsov 14*9ad6634eSVitaly KuznetsovKVM on x86 implements Hyper-V Enlightenments for Windows guests. These features 15*9ad6634eSVitaly Kuznetsovmake Windows and Hyper-V guests think they're running on top of a Hyper-V 16*9ad6634eSVitaly Kuznetsovcompatible hypervisor and use Hyper-V specific features. 17*9ad6634eSVitaly Kuznetsov 18*9ad6634eSVitaly Kuznetsov 19*9ad6634eSVitaly KuznetsovSetup 20*9ad6634eSVitaly Kuznetsov----- 21*9ad6634eSVitaly Kuznetsov 22*9ad6634eSVitaly KuznetsovNo Hyper-V enlightenments are enabled by default by either KVM or QEMU. In 23*9ad6634eSVitaly KuznetsovQEMU, individual enlightenments can be enabled through CPU flags, e.g: 24*9ad6634eSVitaly Kuznetsov 25*9ad6634eSVitaly Kuznetsov.. parsed-literal:: 26*9ad6634eSVitaly Kuznetsov 27*9ad6634eSVitaly Kuznetsov |qemu_system| --enable-kvm --cpu host,hv_relaxed,hv_vpindex,hv_time, ... 28*9ad6634eSVitaly Kuznetsov 29*9ad6634eSVitaly KuznetsovSometimes there are dependencies between enlightenments, QEMU is supposed to 30*9ad6634eSVitaly Kuznetsovcheck that the supplied configuration is sane. 31*9ad6634eSVitaly Kuznetsov 32*9ad6634eSVitaly KuznetsovWhen any set of the Hyper-V enlightenments is enabled, QEMU changes hypervisor 33*9ad6634eSVitaly Kuznetsovidentification (CPUID 0x40000000..0x4000000A) to Hyper-V. KVM identification 34*9ad6634eSVitaly Kuznetsovand features are kept in leaves 0x40000100..0x40000101. 35*9ad6634eSVitaly Kuznetsov 36*9ad6634eSVitaly Kuznetsov 37*9ad6634eSVitaly KuznetsovExisting enlightenments 38*9ad6634eSVitaly Kuznetsov----------------------- 39*9ad6634eSVitaly Kuznetsov 40*9ad6634eSVitaly Kuznetsov``hv-relaxed`` 41*9ad6634eSVitaly Kuznetsov This feature tells guest OS to disable watchdog timeouts as it is running on a 42*9ad6634eSVitaly Kuznetsov hypervisor. It is known that some Windows versions will do this even when they 43*9ad6634eSVitaly Kuznetsov see 'hypervisor' CPU flag. 44*9ad6634eSVitaly Kuznetsov 45*9ad6634eSVitaly Kuznetsov``hv-vapic`` 46*9ad6634eSVitaly Kuznetsov Provides so-called VP Assist page MSR to guest allowing it to work with APIC 47*9ad6634eSVitaly Kuznetsov more efficiently. In particular, this enlightenment allows paravirtualized 48*9ad6634eSVitaly Kuznetsov (exit-less) EOI processing. 49*9ad6634eSVitaly Kuznetsov 50*9ad6634eSVitaly Kuznetsov``hv-spinlocks`` = xxx 51*9ad6634eSVitaly Kuznetsov Enables paravirtualized spinlocks. The parameter indicates how many times 52*9ad6634eSVitaly Kuznetsov spinlock acquisition should be attempted before indicating the situation to the 53*9ad6634eSVitaly Kuznetsov hypervisor. A special value 0xffffffff indicates "never notify". 54*9ad6634eSVitaly Kuznetsov 55*9ad6634eSVitaly Kuznetsov``hv-vpindex`` 56*9ad6634eSVitaly Kuznetsov Provides HV_X64_MSR_VP_INDEX (0x40000002) MSR to the guest which has Virtual 57*9ad6634eSVitaly Kuznetsov processor index information. This enlightenment makes sense in conjunction with 58*9ad6634eSVitaly Kuznetsov hv-synic, hv-stimer and other enlightenments which require the guest to know its 59*9ad6634eSVitaly Kuznetsov Virtual Processor indices (e.g. when VP index needs to be passed in a 60*9ad6634eSVitaly Kuznetsov hypercall). 61*9ad6634eSVitaly Kuznetsov 62*9ad6634eSVitaly Kuznetsov``hv-runtime`` 63*9ad6634eSVitaly Kuznetsov Provides HV_X64_MSR_VP_RUNTIME (0x40000010) MSR to the guest. The MSR keeps the 64*9ad6634eSVitaly Kuznetsov virtual processor run time in 100ns units. This gives guest operating system an 65*9ad6634eSVitaly Kuznetsov idea of how much time was 'stolen' from it (when the virtual CPU was preempted 66*9ad6634eSVitaly Kuznetsov to perform some other work). 67*9ad6634eSVitaly Kuznetsov 68*9ad6634eSVitaly Kuznetsov``hv-crash`` 69*9ad6634eSVitaly Kuznetsov Provides HV_X64_MSR_CRASH_P0..HV_X64_MSR_CRASH_P5 (0x40000100..0x40000105) and 70*9ad6634eSVitaly Kuznetsov HV_X64_MSR_CRASH_CTL (0x40000105) MSRs to the guest. These MSRs are written to 71*9ad6634eSVitaly Kuznetsov by the guest when it crashes, HV_X64_MSR_CRASH_P0..HV_X64_MSR_CRASH_P5 MSRs 72*9ad6634eSVitaly Kuznetsov contain additional crash information. This information is outputted in QEMU log 73*9ad6634eSVitaly Kuznetsov and through QAPI. 74*9ad6634eSVitaly Kuznetsov Note: unlike under genuine Hyper-V, write to HV_X64_MSR_CRASH_CTL causes guest 75*9ad6634eSVitaly Kuznetsov to shutdown. This effectively blocks crash dump generation by Windows. 76*9ad6634eSVitaly Kuznetsov 77*9ad6634eSVitaly Kuznetsov``hv-time`` 78*9ad6634eSVitaly Kuznetsov Enables two Hyper-V-specific clocksources available to the guest: MSR-based 79*9ad6634eSVitaly Kuznetsov Hyper-V clocksource (HV_X64_MSR_TIME_REF_COUNT, 0x40000020) and Reference TSC 80*9ad6634eSVitaly Kuznetsov page (enabled via MSR HV_X64_MSR_REFERENCE_TSC, 0x40000021). Both clocksources 81*9ad6634eSVitaly Kuznetsov are per-guest, Reference TSC page clocksource allows for exit-less time stamp 82*9ad6634eSVitaly Kuznetsov readings. Using this enlightenment leads to significant speedup of all timestamp 83*9ad6634eSVitaly Kuznetsov related operations. 84*9ad6634eSVitaly Kuznetsov 85*9ad6634eSVitaly Kuznetsov``hv-synic`` 86*9ad6634eSVitaly Kuznetsov Enables Hyper-V Synthetic interrupt controller - an extension of a local APIC. 87*9ad6634eSVitaly Kuznetsov When enabled, this enlightenment provides additional communication facilities 88*9ad6634eSVitaly Kuznetsov to the guest: SynIC messages and Events. This is a pre-requisite for 89*9ad6634eSVitaly Kuznetsov implementing VMBus devices (not yet in QEMU). Additionally, this enlightenment 90*9ad6634eSVitaly Kuznetsov is needed to enable Hyper-V synthetic timers. SynIC is controlled through MSRs 91*9ad6634eSVitaly Kuznetsov HV_X64_MSR_SCONTROL..HV_X64_MSR_EOM (0x40000080..0x40000084) and 92*9ad6634eSVitaly Kuznetsov HV_X64_MSR_SINT0..HV_X64_MSR_SINT15 (0x40000090..0x4000009F) 93*9ad6634eSVitaly Kuznetsov 94*9ad6634eSVitaly Kuznetsov Requires: ``hv-vpindex`` 95*9ad6634eSVitaly Kuznetsov 96*9ad6634eSVitaly Kuznetsov``hv-stimer`` 97*9ad6634eSVitaly Kuznetsov Enables Hyper-V synthetic timers. There are four synthetic timers per virtual 98*9ad6634eSVitaly Kuznetsov CPU controlled through HV_X64_MSR_STIMER0_CONFIG..HV_X64_MSR_STIMER3_COUNT 99*9ad6634eSVitaly Kuznetsov (0x400000B0..0x400000B7) MSRs. These timers can work either in single-shot or 100*9ad6634eSVitaly Kuznetsov periodic mode. It is known that certain Windows versions revert to using HPET 101*9ad6634eSVitaly Kuznetsov (or even RTC when HPET is unavailable) extensively when this enlightenment is 102*9ad6634eSVitaly Kuznetsov not provided; this can lead to significant CPU consumption, even when virtual 103*9ad6634eSVitaly Kuznetsov CPU is idle. 104*9ad6634eSVitaly Kuznetsov 105*9ad6634eSVitaly Kuznetsov Requires: ``hv-vpindex``, ``hv-synic``, ``hv-time`` 106*9ad6634eSVitaly Kuznetsov 107*9ad6634eSVitaly Kuznetsov``hv-tlbflush`` 108*9ad6634eSVitaly Kuznetsov Enables paravirtualized TLB shoot-down mechanism. On x86 architecture, remote 109*9ad6634eSVitaly Kuznetsov TLB flush procedure requires sending IPIs and waiting for other CPUs to perform 110*9ad6634eSVitaly Kuznetsov local TLB flush. In virtualized environment some virtual CPUs may not even be 111*9ad6634eSVitaly Kuznetsov scheduled at the time of the call and may not require flushing (or, flushing 112*9ad6634eSVitaly Kuznetsov may be postponed until the virtual CPU is scheduled). hv-tlbflush enlightenment 113*9ad6634eSVitaly Kuznetsov implements TLB shoot-down through hypervisor enabling the optimization. 114*9ad6634eSVitaly Kuznetsov 115*9ad6634eSVitaly Kuznetsov Requires: ``hv-vpindex`` 116*9ad6634eSVitaly Kuznetsov 117*9ad6634eSVitaly Kuznetsov``hv-ipi`` 118*9ad6634eSVitaly Kuznetsov Enables paravirtualized IPI send mechanism. HvCallSendSyntheticClusterIpi 119*9ad6634eSVitaly Kuznetsov hypercall may target more than 64 virtual CPUs simultaneously, doing the same 120*9ad6634eSVitaly Kuznetsov through APIC requires more than one access (and thus exit to the hypervisor). 121*9ad6634eSVitaly Kuznetsov 122*9ad6634eSVitaly Kuznetsov Requires: ``hv-vpindex`` 123*9ad6634eSVitaly Kuznetsov 124*9ad6634eSVitaly Kuznetsov``hv-vendor-id`` = xxx 125*9ad6634eSVitaly Kuznetsov This changes Hyper-V identification in CPUID 0x40000000.EBX-EDX from the default 126*9ad6634eSVitaly Kuznetsov "Microsoft Hv". The parameter should be no longer than 12 characters. According 127*9ad6634eSVitaly Kuznetsov to the specification, guests shouldn't use this information and it is unknown 128*9ad6634eSVitaly Kuznetsov if there is a Windows version which acts differently. 129*9ad6634eSVitaly Kuznetsov Note: hv-vendor-id is not an enlightenment and thus doesn't enable Hyper-V 130*9ad6634eSVitaly Kuznetsov identification when specified without some other enlightenment. 131*9ad6634eSVitaly Kuznetsov 132*9ad6634eSVitaly Kuznetsov``hv-reset`` 133*9ad6634eSVitaly Kuznetsov Provides HV_X64_MSR_RESET (0x40000003) MSR to the guest allowing it to reset 134*9ad6634eSVitaly Kuznetsov itself by writing to it. Even when this MSR is enabled, it is not a recommended 135*9ad6634eSVitaly Kuznetsov way for Windows to perform system reboot and thus it may not be used. 136*9ad6634eSVitaly Kuznetsov 137*9ad6634eSVitaly Kuznetsov``hv-frequencies`` 138*9ad6634eSVitaly Kuznetsov Provides HV_X64_MSR_TSC_FREQUENCY (0x40000022) and HV_X64_MSR_APIC_FREQUENCY 139*9ad6634eSVitaly Kuznetsov (0x40000023) allowing the guest to get its TSC/APIC frequencies without doing 140*9ad6634eSVitaly Kuznetsov measurements. 141*9ad6634eSVitaly Kuznetsov 142*9ad6634eSVitaly Kuznetsov``hv-reenlightenment`` 143*9ad6634eSVitaly Kuznetsov The enlightenment is nested specific, it targets Hyper-V on KVM guests. When 144*9ad6634eSVitaly Kuznetsov enabled, it provides HV_X64_MSR_REENLIGHTENMENT_CONTROL (0x40000106), 145*9ad6634eSVitaly Kuznetsov HV_X64_MSR_TSC_EMULATION_CONTROL (0x40000107)and HV_X64_MSR_TSC_EMULATION_STATUS 146*9ad6634eSVitaly Kuznetsov (0x40000108) MSRs allowing the guest to get notified when TSC frequency changes 147*9ad6634eSVitaly Kuznetsov (only happens on migration) and keep using old frequency (through emulation in 148*9ad6634eSVitaly Kuznetsov the hypervisor) until it is ready to switch to the new one. This, in conjunction 149*9ad6634eSVitaly Kuznetsov with ``hv-frequencies``, allows Hyper-V on KVM to pass stable clocksource 150*9ad6634eSVitaly Kuznetsov (Reference TSC page) to its own guests. 151*9ad6634eSVitaly Kuznetsov 152*9ad6634eSVitaly Kuznetsov Note, KVM doesn't fully support re-enlightenment notifications and doesn't 153*9ad6634eSVitaly Kuznetsov emulate TSC accesses after migration so 'tsc-frequency=' CPU option also has to 154*9ad6634eSVitaly Kuznetsov be specified to make migration succeed. The destination host has to either have 155*9ad6634eSVitaly Kuznetsov the same TSC frequency or support TSC scaling CPU feature. 156*9ad6634eSVitaly Kuznetsov 157*9ad6634eSVitaly Kuznetsov Recommended: ``hv-frequencies`` 158*9ad6634eSVitaly Kuznetsov 159*9ad6634eSVitaly Kuznetsov``hv-evmcs`` 160*9ad6634eSVitaly Kuznetsov The enlightenment is nested specific, it targets Hyper-V on KVM guests. When 161*9ad6634eSVitaly Kuznetsov enabled, it provides Enlightened VMCS version 1 feature to the guest. The feature 162*9ad6634eSVitaly Kuznetsov implements paravirtualized protocol between L0 (KVM) and L1 (Hyper-V) 163*9ad6634eSVitaly Kuznetsov hypervisors making L2 exits to the hypervisor faster. The feature is Intel-only. 164*9ad6634eSVitaly Kuznetsov 165*9ad6634eSVitaly Kuznetsov Note: some virtualization features (e.g. Posted Interrupts) are disabled when 166*9ad6634eSVitaly Kuznetsov hv-evmcs is enabled. It may make sense to measure your nested workload with and 167*9ad6634eSVitaly Kuznetsov without the feature to find out if enabling it is beneficial. 168*9ad6634eSVitaly Kuznetsov 169*9ad6634eSVitaly Kuznetsov Requires: ``hv-vapic`` 170*9ad6634eSVitaly Kuznetsov 171*9ad6634eSVitaly Kuznetsov``hv-stimer-direct`` 172*9ad6634eSVitaly Kuznetsov Hyper-V specification allows synthetic timer operation in two modes: "classic", 173*9ad6634eSVitaly Kuznetsov when expiration event is delivered as SynIC message and "direct", when the event 174*9ad6634eSVitaly Kuznetsov is delivered via normal interrupt. It is known that nested Hyper-V can only 175*9ad6634eSVitaly Kuznetsov use synthetic timers in direct mode and thus ``hv-stimer-direct`` needs to be 176*9ad6634eSVitaly Kuznetsov enabled. 177*9ad6634eSVitaly Kuznetsov 178*9ad6634eSVitaly Kuznetsov Requires: ``hv-vpindex``, ``hv-synic``, ``hv-time``, ``hv-stimer`` 179*9ad6634eSVitaly Kuznetsov 180*9ad6634eSVitaly Kuznetsov``hv-avic`` (``hv-apicv``) 181*9ad6634eSVitaly Kuznetsov The enlightenment allows to use Hyper-V SynIC with hardware APICv/AVIC enabled. 182*9ad6634eSVitaly Kuznetsov Normally, Hyper-V SynIC disables these hardware feature and suggests the guest 183*9ad6634eSVitaly Kuznetsov to use paravirtualized AutoEOI feature. 184*9ad6634eSVitaly Kuznetsov Note: enabling this feature on old hardware (without APICv/AVIC support) may 185*9ad6634eSVitaly Kuznetsov have negative effect on guest's performance. 186*9ad6634eSVitaly Kuznetsov 187*9ad6634eSVitaly Kuznetsov``hv-no-nonarch-coresharing`` = on/off/auto 188*9ad6634eSVitaly Kuznetsov This enlightenment tells guest OS that virtual processors will never share a 189*9ad6634eSVitaly Kuznetsov physical core unless they are reported as sibling SMT threads. This information 190*9ad6634eSVitaly Kuznetsov is required by Windows and Hyper-V guests to properly mitigate SMT related CPU 191*9ad6634eSVitaly Kuznetsov vulnerabilities. 192*9ad6634eSVitaly Kuznetsov 193*9ad6634eSVitaly Kuznetsov When the option is set to 'auto' QEMU will enable the feature only when KVM 194*9ad6634eSVitaly Kuznetsov reports that non-architectural coresharing is impossible, this means that 195*9ad6634eSVitaly Kuznetsov hyper-threading is not supported or completely disabled on the host. This 196*9ad6634eSVitaly Kuznetsov setting also prevents migration as SMT settings on the destination may differ. 197*9ad6634eSVitaly Kuznetsov When the option is set to 'on' QEMU will always enable the feature, regardless 198*9ad6634eSVitaly Kuznetsov of host setup. To keep guests secure, this can only be used in conjunction with 199*9ad6634eSVitaly Kuznetsov exposing correct vCPU topology and vCPU pinning. 200*9ad6634eSVitaly Kuznetsov 201*9ad6634eSVitaly Kuznetsov``hv-version-id-build``, ``hv-version-id-major``, ``hv-version-id-minor``, ``hv-version-id-spack``, ``hv-version-id-sbranch``, ``hv-version-id-snumber`` 202*9ad6634eSVitaly Kuznetsov This changes Hyper-V version identification in CPUID 0x40000002.EAX-EDX from the 203*9ad6634eSVitaly Kuznetsov default (WS2016). 204*9ad6634eSVitaly Kuznetsov 205*9ad6634eSVitaly Kuznetsov - ``hv-version-id-build`` sets 'Build Number' (32 bits) 206*9ad6634eSVitaly Kuznetsov - ``hv-version-id-major`` sets 'Major Version' (16 bits) 207*9ad6634eSVitaly Kuznetsov - ``hv-version-id-minor`` sets 'Minor Version' (16 bits) 208*9ad6634eSVitaly Kuznetsov - ``hv-version-id-spack`` sets 'Service Pack' (32 bits) 209*9ad6634eSVitaly Kuznetsov - ``hv-version-id-sbranch`` sets 'Service Branch' (8 bits) 210*9ad6634eSVitaly Kuznetsov - ``hv-version-id-snumber`` sets 'Service Number' (24 bits) 211*9ad6634eSVitaly Kuznetsov 212*9ad6634eSVitaly Kuznetsov Note: hv-version-id-* are not enlightenments and thus don't enable Hyper-V 213*9ad6634eSVitaly Kuznetsov identification when specified without any other enlightenments. 214*9ad6634eSVitaly Kuznetsov 215*9ad6634eSVitaly Kuznetsov``hv-syndbg`` 216*9ad6634eSVitaly Kuznetsov Enables Hyper-V synthetic debugger interface, this is a special interface used 217*9ad6634eSVitaly Kuznetsov by Windows Kernel debugger to send the packets through, rather than sending 218*9ad6634eSVitaly Kuznetsov them via serial/network . 219*9ad6634eSVitaly Kuznetsov When enabled, this enlightenment provides additional communication facilities 220*9ad6634eSVitaly Kuznetsov to the guest: SynDbg messages. 221*9ad6634eSVitaly Kuznetsov This new communication is used by Windows Kernel debugger rather than sending 222*9ad6634eSVitaly Kuznetsov packets via serial/network, adding significant performance boost over the other 223*9ad6634eSVitaly Kuznetsov comm channels. 224*9ad6634eSVitaly Kuznetsov This enlightenment requires a VMBus device (-device vmbus-bridge,irq=15). 225*9ad6634eSVitaly Kuznetsov 226*9ad6634eSVitaly Kuznetsov Requires: ``hv-relaxed``, ``hv_time``, ``hv-vapic``, ``hv-vpindex``, ``hv-synic``, ``hv-runtime``, ``hv-stimer`` 227*9ad6634eSVitaly Kuznetsov 228*9ad6634eSVitaly Kuznetsov``hv-emsr-bitmap`` 229*9ad6634eSVitaly Kuznetsov The enlightenment is nested specific, it targets Hyper-V on KVM guests. When 230*9ad6634eSVitaly Kuznetsov enabled, it allows L0 (KVM) and L1 (Hyper-V) hypervisors to collaborate to 231*9ad6634eSVitaly Kuznetsov avoid unnecessary updates to L2 MSR-Bitmap upon vmexits. While the protocol is 232*9ad6634eSVitaly Kuznetsov supported for both VMX (Intel) and SVM (AMD), the VMX implementation requires 233*9ad6634eSVitaly Kuznetsov Enlightened VMCS (``hv-evmcs``) feature to also be enabled. 234*9ad6634eSVitaly Kuznetsov 235*9ad6634eSVitaly Kuznetsov Recommended: ``hv-evmcs`` (Intel) 236*9ad6634eSVitaly Kuznetsov 237*9ad6634eSVitaly Kuznetsov``hv-xmm-input`` 238*9ad6634eSVitaly Kuznetsov Hyper-V specification allows to pass parameters for certain hypercalls using XMM 239*9ad6634eSVitaly Kuznetsov registers ("XMM Fast Hypercall Input"). When the feature is in use, it allows 240*9ad6634eSVitaly Kuznetsov for faster hypercalls processing as KVM can avoid reading guest's memory. 241*9ad6634eSVitaly Kuznetsov 242*9ad6634eSVitaly Kuznetsov``hv-tlbflush-ext`` 243*9ad6634eSVitaly Kuznetsov Allow for extended GVA ranges to be passed to Hyper-V TLB flush hypercalls 244*9ad6634eSVitaly Kuznetsov (HvFlushVirtualAddressList/HvFlushVirtualAddressListEx). 245*9ad6634eSVitaly Kuznetsov 246*9ad6634eSVitaly Kuznetsov Requires: ``hv-tlbflush`` 247*9ad6634eSVitaly Kuznetsov 248*9ad6634eSVitaly Kuznetsov``hv-tlbflush-direct`` 249*9ad6634eSVitaly Kuznetsov The enlightenment is nested specific, it targets Hyper-V on KVM guests. When 250*9ad6634eSVitaly Kuznetsov enabled, it allows L0 (KVM) to directly handle TLB flush hypercalls from L2 251*9ad6634eSVitaly Kuznetsov guest without the need to exit to L1 (Hyper-V) hypervisor. While the feature is 252*9ad6634eSVitaly Kuznetsov supported for both VMX (Intel) and SVM (AMD), the VMX implementation requires 253*9ad6634eSVitaly Kuznetsov Enlightened VMCS (``hv-evmcs``) feature to also be enabled. 254*9ad6634eSVitaly Kuznetsov 255*9ad6634eSVitaly Kuznetsov Requires: ``hv-vapic`` 256*9ad6634eSVitaly Kuznetsov 257*9ad6634eSVitaly Kuznetsov Recommended: ``hv-evmcs`` (Intel) 258*9ad6634eSVitaly Kuznetsov 259*9ad6634eSVitaly KuznetsovSupplementary features 260*9ad6634eSVitaly Kuznetsov---------------------- 261*9ad6634eSVitaly Kuznetsov 262*9ad6634eSVitaly Kuznetsov``hv-passthrough`` 263*9ad6634eSVitaly Kuznetsov In some cases (e.g. during development) it may make sense to use QEMU in 264*9ad6634eSVitaly Kuznetsov 'pass-through' mode and give Windows guests all enlightenments currently 265*9ad6634eSVitaly Kuznetsov supported by KVM. This pass-through mode is enabled by "hv-passthrough" CPU 266*9ad6634eSVitaly Kuznetsov flag. 267*9ad6634eSVitaly Kuznetsov 268*9ad6634eSVitaly Kuznetsov Note: ``hv-passthrough`` flag only enables enlightenments which are known to QEMU 269*9ad6634eSVitaly Kuznetsov (have corresponding 'hv-' flag) and copies ``hv-spinlocks`` and ``hv-vendor-id`` 270*9ad6634eSVitaly Kuznetsov values from KVM to QEMU. ``hv-passthrough`` overrides all other 'hv-' settings on 271*9ad6634eSVitaly Kuznetsov the command line. Also, enabling this flag effectively prevents migration as the 272*9ad6634eSVitaly Kuznetsov list of enabled enlightenments may differ between target and destination hosts. 273*9ad6634eSVitaly Kuznetsov 274*9ad6634eSVitaly Kuznetsov``hv-enforce-cpuid`` 275*9ad6634eSVitaly Kuznetsov By default, KVM allows the guest to use all currently supported Hyper-V 276*9ad6634eSVitaly Kuznetsov enlightenments when Hyper-V CPUID interface was exposed, regardless of if 277*9ad6634eSVitaly Kuznetsov some features were not announced in guest visible CPUIDs. ``hv-enforce-cpuid`` 278*9ad6634eSVitaly Kuznetsov feature alters this behavior and only allows the guest to use exposed Hyper-V 279*9ad6634eSVitaly Kuznetsov enlightenments. 280*9ad6634eSVitaly Kuznetsov 281*9ad6634eSVitaly Kuznetsov 282*9ad6634eSVitaly KuznetsovUseful links 283*9ad6634eSVitaly Kuznetsov------------ 284*9ad6634eSVitaly KuznetsovHyper-V Top Level Functional specification and other information: 285*9ad6634eSVitaly Kuznetsov 286*9ad6634eSVitaly Kuznetsov- https://github.com/MicrosoftDocs/Virtualization-Documentation 287*9ad6634eSVitaly Kuznetsov- https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/tlfs 288*9ad6634eSVitaly Kuznetsov 289