Re: [RFC PATCH] Add Hyperv extended hypercall support in KVM

[Sean Christopherson <seanjc@google.com>]

On Fri, Oct 21, 2022, Vipin Sharma wrote:
> On Fri, Oct 21, 2022 at 1:13 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Fri, Oct 21, 2022, Vipin Sharma wrote:
> > > Hyperv hypercalls above 0x8000 are called as extended hypercalls as per
> > > Hyperv TLFS. Hypercall 0x8001 is used to enquire about available
> > > hypercalls by guest VMs.
> > >
> > > Add support for HvExtCallQueryCapabilities (0x8001) and
> > > HvExtCallGetBootZeroedMemory (0x8002) in KVM.
> > >
> > > A guest VM finds availability of HvExtCallQueryCapabilities (0x8001) by
> > > using CPUID.0x40000003.EBX BIT(20). If the bit is set then the guest VM
> > > make hypercall HvExtCallQueryCapabilities (0x8001) to know what all
> > > extended hypercalls are supported by hypervisor.
> > >
> > > A userspace VMM can query capability KVM_CAP_HYPERV_EXT_CALL_QUERY to
> > > know which extended hypercalls are supported in KVM. After which the
> > > userspace will enable capabilities for the guest VM.
> > >
> > > HvExtCallQueryCapabilities (0x8001) is handled by KVM in kernel,
> >
> > Does this really need to be handle by KVM?  I assume this is a rare operation,
> > e.g. done once during guest boot, so performance shouldn't be a concern.  To
> > avoid breaking existing userspace, KVM can forward HV_EXT_CALL_GET_BOOT_ZEROED_MEMORY
> > to userspace if and only if HV_ENABLE_EXTENDED_HYPERCALLS is enabled in CPUID,
> > but otherwise KVM can let userspace deal with the "is this enabled" check.
> 
> There are 4 more extended hypercalls mentioned in TLFS but there is no
> detail about them in the document. From the linux source code one of
> the hypercall HvExtCallMemoryHeatHint (0x8003) is a repetitive call.
> In the file drivers/hv/hv_balloon.c
>           status = hv_do_rep_hypercall(HV_EXT_CALL_MEMORY_HEAT_HINT,
> nents, 0,  hint, NULL);
> 
> This makes me a little bit wary that these hypercalls or any future
> hypercalls can have high calling frequency by Windows guest. Also, it
> is not clear which calls can or cannot be satisfied by userspace
> alone.

If future support needs to be moved into KVM, e.g. for performance reasons, then
we can do that if necessary.  

> So, I am not sure if the default exit to userspace for all of the
> extended hypercalls will be future proof, therefore, I went with the
> approach of only selectively exiting to userspace based on hypercall.

But punting on everything _might_ be future proof, whereas the only way that
selectively exiting ends up being future proof is if no one ever wants to support
another extended hypercall.