On Fri, Oct 21, 2022, Vipin Sharma wrote: > On Fri, Oct 21, 2022 at 1:13 PM Sean Christopherson <seanjc@xxxxxxxxxx> 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.
