Tianyu Lan <lantianyu1986@xxxxxxxxx> writes: > On Tue, Aug 27, 2019 at 2:41 PM Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> wrote: >> >> 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)). >> > > Hi Vitaly:: > Actually, I had such idea before. But user space should check > whether hv tlb flush > is exposed to VM before enabling direct tlb flush. If no, user space > should not direct > tlb flush for guest since Hyper-V will do more check for each > hypercall from nested > VM with enabling the feauter.. If TLB Flush enlightenment is not exposed to the VM at all there's no difference if we enable direct TLB flush in eVMCS or not: the guest won't be using 'TLB Flush' hypercall and will do TLB flushing with IPIs. And, in case the guest enables Hyper-V hypercall page, it is definitelly not going to use KVM hypercalls so we can't break these. -- Vitaly
