[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZS1VGvbcmH93-KyH@google.com>
Date: Mon, 16 Oct 2023 08:27:01 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>
Cc: Maxim Levitsky <mlevitsk@...hat.com>, kvm@...r.kernel.org,
Paolo Bonzini <pbonzini@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 07/11] KVM: x86: Make Hyper-V emulation optional
On Mon, Oct 16, 2023, Vitaly Kuznetsov wrote:
> Maxim Levitsky <mlevitsk@...hat.com> writes:
>
> > У вт, 2023-10-10 у 18:02 +0200, Vitaly Kuznetsov пише:
> >> Hyper-V emulation in KVM is a fairly big chunk and in some cases it may be
> >> desirable to not compile it in to reduce module sizes as well as attack
> >> surface. Introduce CONFIG_KVM_HYPERV option to make it possible.
> >>
> >> Note, there's room for further nVMX/nSVM code optimizations when
> >> !CONFIG_KVM_HYPERV, this will be done in follow-up patches.
> >
> > Maybe CONFIG_KVM_HYPERV_GUEST_SUPPORT or CONFIG_HYPERV_ON_KVM instead?
> >
> > IMHO CONFIG_KVM_HYPERV_GUEST_SUPPORT sounds good.
Adding GUEST_SUPPORT doesn't disambiguate anything though, as there's no clear
indication of whether KVM or Hyper-V is the guest. E.g. the umbrella kconfig for
Linux-as-a-guest is CONFIG_HYPERVISOR_GUEST.
> We already have CONFIG_KVM_XEN so I decided to stay concise. I do
> understand that 'KVM-on-Hyper-V' and 'Hyper-V-on-KVM' mess which creates
> the confusion though.
Yeah, matching Xen is probably the best way to minimize confusion, e.g. the kernel
has CONFIG_HYPERV and CONFIG_XEN to go with KVM's, CONFIG_KVM_HYPERV and CONFIG_KVM_XEN.
> >> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> >> index ed90f148140d..a06e19a8a8f6 100644
> >> --- a/arch/x86/kvm/Kconfig
> >> +++ b/arch/x86/kvm/Kconfig
> >> @@ -129,6 +129,15 @@ config KVM_SMM
> >>
> >> If unsure, say Y.
> >>
> >> +config KVM_HYPERV
> >> + bool "Support for Microsoft Hyper-V emulation"
> >> + depends on KVM
> >> + default y
> >> + help
> >> + Provides KVM support for emulating Microsoft Hypervisor (Hyper-V).
> >
> >
> > It feels to me that the KConfig option can have a longer description.
> >
> > What do you think about something like that:
> >
> > "Provides KVM support for emulating Microsoft Hypervisor (Hyper-V).
I don't think we should put Hyper-V in parentheses, I haven't seen any documentation
that calls it "Microsoft Hypervisor", i.e. Hyper-V is the full and proper name.
> > This makes KVM expose a set of paravirtualized interfaces,
s/makes/allows, since KVM still requires userspace to opt-in to exposing Hyper-V.
> > documented in the HyperV TLFS,
s/TLFS/spec? Readers that aren't already familiar with Hyper-V will have no idea
what TLFS is until they click the link.
> > https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs,
> > which consists of a subset of paravirtualized interfaces that HyperV exposes
We can trim this paragraph by stating that KVM only supports a subset of the
PV interfaces straightaway.
> > to its guests.
E.g.
Provides KVM support for for emulating Microsoft Hyper-V. This allows KVM to
expose a subset of the paravirtualized interfaces defined in Hyper-V's spec:
https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs.
> >
> > This improves performance of modern Windows guests.
Isn't Hyper-V emulation effectively mandatory these days? IIRC, modern versions
of Windows will fail to boot if they detect a hypervisor but the core Hyper-V
interfaces aren't supported.
Powered by blists - more mailing lists