Zhao Liu <zhao1....@intel.com> writes: > Hi Vitaly, > > On Tue, Mar 05, 2024 at 05:42:04PM +0100, Vitaly Kuznetsov wrote: >> Date: Tue, 5 Mar 2024 17:42:04 +0100 >> From: Vitaly Kuznetsov <vkuzn...@redhat.com> >> Subject: [PATCH RESEND v3 3/3] docs/system: Add recommendations to Hyper-V >> enlightenments doc >> >> While hyperv.rst already has all currently implemented Hyper-V >> enlightenments documented, it may be unclear what is the recommended set to >> achieve the best result. Add the corresponding section to the doc. >> >> Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> >> --- >> docs/system/i386/hyperv.rst | 30 ++++++++++++++++++++++++++++++ >> 1 file changed, 30 insertions(+) >> >> diff --git a/docs/system/i386/hyperv.rst b/docs/system/i386/hyperv.rst >> index 009947e39141..1c1de77feb65 100644 >> --- a/docs/system/i386/hyperv.rst >> +++ b/docs/system/i386/hyperv.rst >> @@ -283,6 +283,36 @@ Supplementary features >> feature alters this behavior and only allows the guest to use exposed >> Hyper-V >> enlightenments. >> >> +Recommendations >> +--------------- > > This guide is very helpful! > >> +To achieve the best performance of Windows and Hyper-V guests and unless >> there >> +are any specific requirements (e.g. migration to older QEMU/KVM versions, >> +emulating specific Hyper-V version, ...), it is recommended to enable all >> +currently implemented Hyper-V enlightenments with the following exceptions: >> + >> +- ``hv-syndbg``, ``hv-passthrough``, ``hv-enforce-cpuid`` should not be >> enabled >> + in production configurations as these are debugging/development features. >> +- ``hv-reset`` can be avoided as modern Hyper-V versions don't expose it. > > Does the "Hyper-V versions" means Hyper-V guest version or Microsoft's Hyper-V > hypervisor version? > It would be better to clarify Hyper-V guest and Hyper-v hypervisor. > > And it would be better to have a clear version number.
This is about QEMU/KVM emulating certain Hyper-V version, not about guest Hyper-V version. To be honest, I'm not sure what was the last version of Hyper-V which was exposing HV_SYSTEM_RESET_RECOMMENDED. I don't have anything older that WS2016 around now and the bit is not there. If I'm not mistaken, it was already missing in 2012R2. I would appreciate if anyone has more precise historical info to add here. > >> +- ``hv-evmcs`` can (and should) be enabled on Intel CPUs only. While the >> feature >> + is only used in nested configurations (Hyper-V, WSL2), enabling it for >> regular >> + Windows guests should not have any negative effects. >> +- ``hv-no-nonarch-coresharing`` must only be enabled if vCPUs are properly >> pinned >> + so no non-architectural core sharing is possible. >> +- ``hv-vendor-id``, ``hv-version-id-build``, ``hv-version-id-major``, >> + ``hv-version-id-minor``, ``hv-version-id-spack``, >> ``hv-version-id-sbranch``, >> + ``hv-version-id-snumber`` can be left unchanged, guests are not supposed >> to >> + behave differently when different Hyper-V version is presented to them. >> +- ``hv-crash`` must only be enabled if the crash information is consumed via >> + QAPI by higher levels of the virtualization stack. Enabling this feature >> + effectively prevents Windows from creating dumps upon crashes. >> +- ``hv-reenlightenment`` can only be used on hardware which supports TSC >> + scaling or when guest migration is not needed. >> +- ``hv-spinlocks`` should be set to e.g. 0xfff when host CPUs are >> overcommited >> + (meaning there are other scheduled tasks or guests) and can be left >> unchanged >> + from the default value (0xffffffff) otherwise. >> +- ``hv-avic``/``hv-apicv`` should not be enabled if the hardware does not >> + support APIC virtualization (Intel APICv, AMD AVIC). >> > > It's also better to add blank lines between paragraphs above. Np, if I am to re-send this I'll add these (hope it's not an acceptance blocker, we can always do a follow-up). > > BTW, may I ask another Windows question? I understand that Windows such > as Windows 10 and later is already a virtualized architecture with > built-in Hyper-V to run root partation. > > So is it true that booting Windows VM via KVM + QEMU is running Windows > Guest in L2? Or what is the relationship between Hyper-V within Windows > and Hyper-V enlightenments with QEMU + KVM? Hyper-V is a role you can enable in various Windows versions, both server and client. When enabled, you get a hypervisor (which is called 'Microsoft Hypervisor' as I was told) and your Windows becomes the root partition (similar to Xen Dom0). In case you run this on KVM, Windows becomes L2. Hyper-V enlightenments provided by KVM/QEMU are consumed by the hypervisor then. Note: Hyper-V role is optional, in many cases Windows guests run without it (no Hyper-V VMs, no WSL2, ...) and thus consume KVM's Hyper-V enlightenments directly, no nested virt involved. -- Vitaly
