| Message ID | 20240305164204.525575-4-vkuznets@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | i386: Fix Hyper-V Gen1 guests stuck on boot with 'hv-passthrough' | expand |
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 <vkuznets@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 <vkuznets@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. > +- ``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. 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? Thanks, Zhao
Zhao Liu <zhao1.liu@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 <vkuznets@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 <vkuznets@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.
> 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. Thanks much for your explanation! Regards, Zhao
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 +--------------- + +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. +- ``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). Useful links ------------
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 <vkuznets@redhat.com> --- docs/system/i386/hyperv.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)