lantianyu1986@xxxxxxxxx writes: > From: Tianyu Lan <Tianyu.Lan@xxxxxxxxxxxxx> > > This patchset is to add Hyper-V direct tlb support in KVM. Hyper-V > in L0 can delegate L1 hypervisor to handle tlb flush request from > L2 guest when direct tlb flush is enabled in L1. > > Patch 2 introduces new cap KVM_CAP_HYPERV_DIRECT_TLBFLUSH to enable > feature from user space. User space should enable this feature only > when Hyper-V hypervisor capability is exposed to guest and KVM profile > is hided. There is a parameter conflict between KVM and Hyper-V hypercall. > We hope L2 guest doesn't use KVM hypercall when the feature is > enabled. Detail please see comment of new API > "KVM_CAP_HYPERV_DIRECT_TLBFLUSH" I was thinking about this for awhile and I think I have a better proposal. Instead of adding this new capability let's enable direct TLB flush when KVM guest enables Hyper-V Hypercall page (writes to HV_X64_MSR_HYPERCALL) - this guarantees that the guest doesn't need KVM hypercalls as we can't handle both KVM-style and Hyper-V-style hypercalls simultaneously and kvm_emulate_hypercall() does: if (kvm_hv_hypercall_enabled(vcpu->kvm)) return kvm_hv_hypercall(vcpu); What do you think? (and instead of adding the capability we can add kvm.ko module parameter to enable direct tlb flush unconditionally, like 'hv_direct_tlbflush=-1/0/1' with '-1' being the default (autoselect based on Hyper-V hypercall enablement, '0' - permanently disabled, '1' - permanenetly enabled)). -- Vitaly
