summaryrefslogtreecommitdiffstats
path: root/docs/hyperv.txt
Commit message (Collapse)AuthorAgeFilesLines
* i386/kvm: correct the meaning of '0xffffffff' value for hv-spinlocksVitaly Kuznetsov2020-09-181-1/+1
| | | | | | | | | | | | Hyper-V TLFS prior to version 6.0 had a mistake in it: special value '0xffffffff' for CPUID 0x40000004.EBX was called 'never to retry', this looked weird (like why it's not '0' which supposedly have the same effect?) but nobody raised the question. In TLFS version 6.0 the mistake was corrected to 'never notify' which sounds logical. Fix QEMU accordingly. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20200515114847.74523-1-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* i386/kvm: add NoNonArchitecturalCoreSharing Hyper-V enlightenmentVitaly Kuznetsov2019-10-221-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hyper-V TLFS specifies this enlightenment as: "NoNonArchitecturalCoreSharing - Indicates that a virtual processor will never share a physical core with another virtual processor, except for virtual processors that are reported as sibling SMT threads. This can be used as an optimization to avoid the performance overhead of STIBP". However, STIBP is not the only implication. It was found that Hyper-V on KVM doesn't pass MD_CLEAR bit to its guests if it doesn't see NoNonArchitecturalCoreSharing bit. KVM reports NoNonArchitecturalCoreSharing in KVM_GET_SUPPORTED_HV_CPUID to indicate that SMT on the host is impossible (not supported of forcefully disabled). Implement NoNonArchitecturalCoreSharing support in QEMU as tristate: 'off' - the feature is disabled (default) 'on' - the feature is enabled. This is only safe if vCPUS are properly pinned and correct topology is exposed. As CPU pinning is done outside of QEMU the enablement decision will be made on a higher level. 'auto' - copy KVM setting. As during live migration SMT settings on the source and destination host may differ this requires us to add a migration blocker. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20191018163908.10246-1-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386/kvm: add support for Direct Mode for Hyper-V synthetic timersVitaly Kuznetsov2019-06-211-0/+10
| | | | | | | | | | Hyper-V on KVM can only use Synthetic timers with Direct Mode (opting for an interrupt instead of VMBus message). This new capability is only announced in KVM_GET_SUPPORTED_HV_CPUID. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-10-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386/kvm: implement 'hv-passthrough' modeVitaly Kuznetsov2019-06-211-0/+10
| | | | | | | | | | | | | | | | | | In many case we just want to give Windows guests all currently supported Hyper-V enlightenments and that's where this new mode may come handy. We pass through what was returned by KVM_GET_SUPPORTED_HV_CPUID. hv_cpuid_check_and_set() is modified to also set cpu->hyperv_* flags as we may want to check them later (and we actually do for hv_runtime, hv_synic,...). 'hv-passthrough' is a development only feature, a migration blocker is added to prevent issues while migrating between hosts with different feature sets. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-6-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386/kvm: document existing Hyper-V enlightenmentsVitaly Kuznetsov2019-06-211-0/+181
Currently, there is no doc describing hv-* CPU flags, people are encouraged to get the information from Microsoft Hyper-V Top Level Functional specification (TLFS). There is, however, a bit of QEMU specifics. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-5-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>