Roman Kagan <rkagan@xxxxxxxxxxxxx> writes: > On Tue, Nov 12, 2019 at 11:34:27AM +0800, lantianyu1986@xxxxxxxxx wrote: >> From: Tianyu Lan <Tianyu.Lan@xxxxxxxxxxxxx> >> >> Hyper-V direct tlb flush targets KVM on Hyper-V guest. >> Enable direct TLB flush for its guests meaning that TLB >> flush hypercalls are handled by Level 0 hypervisor (Hyper-V) >> bypassing KVM in Level 1. Due to the different ABI for hypercall >> parameters between Hyper-V and KVM, KVM capabilities should be >> hidden when enable Hyper-V direct tlb flush otherwise KVM >> hypercalls may be intercepted by Hyper-V. Add new parameter >> "hv-direct-tlbflush". Check expose_kvm and Hyper-V tlb flush >> capability status before enabling the feature. >> >> Signed-off-by: Tianyu Lan <Tianyu.Lan@xxxxxxxxxxxxx> >> --- >> Change since v3: >> - Fix logic of Hyper-V passthrough mode with direct >> tlb flush. >> >> Change sicne v2: >> - Update new feature description and name. >> - Change failure print log. >> >> Change since v1: >> - Add direct tlb flush's Hyper-V property and use >> hv_cpuid_check_and_set() to check the dependency of tlbflush >> feature. >> - Make new feature work with Hyper-V passthrough mode. >> --- >> docs/hyperv.txt | 10 ++++++++++ >> target/i386/cpu.c | 2 ++ >> target/i386/cpu.h | 1 + >> target/i386/kvm.c | 24 ++++++++++++++++++++++++ >> 4 files changed, 37 insertions(+) >> >> diff --git a/docs/hyperv.txt b/docs/hyperv.txt >> index 8fdf25c829..140a5c7e44 100644 >> --- a/docs/hyperv.txt >> +++ b/docs/hyperv.txt >> @@ -184,6 +184,16 @@ enabled. >> >> Requires: hv-vpindex, hv-synic, hv-time, hv-stimer >> >> +3.18. hv-direct-tlbflush >> +======================= >> +Enable direct TLB flush for KVM when it is running as a nested >> +hypervisor on top Hyper-V. When enabled, TLB flush hypercalls from L2 >> +guests are being passed through to L0 (Hyper-V) for handling. Due to ABI >> +differences between Hyper-V and KVM hypercalls, L2 guests will not be >> +able to issue KVM hypercalls (as those could be mishanled by L0 >> +Hyper-V), this requires KVM hypervisor signature to be hidden. > > On a second thought, I wonder if this is the only conflict we have. > > In KVM, kvm_emulate_hypercall, when sees Hyper-V hypercalls enabled, > just calls kvm_hv_hypercall and returns. I.e. once the userspace > enables Hyper-V hypercalls (which QEMU does when any of hv_* flags is > given), KVM treats *all* hypercalls as Hyper-V ones and handles *no* KVM > hypercalls. Yes, but only after guest enables Hyper-V hypercalls by writing to HV_X64_MSR_HYPERCALL. E.g. if you run a Linux guest and add a couple hv_* flags on the QEMU command line the guest will still be able to use KVM hypercalls normally becase Linux won't enable Hyper-V hypercall page. > > So, if hiding the KVM hypervisor signature is the only way to prevent the > guest from issuing KVM hypercalls (need to double-check), then, I'm > afraid, we just need to require it as soon as any Hyper-V feature is > enabled. > If we do that we're going to break a lot of setups in the wild which run Linux guests with hv_* flags (e.g. just to keep configuration the same for Windows/Linux or by mistake/misunderstanding). When Hyper-V enlightenments are enabled, KVM signature moves to 0x40000100 so if a guest is still able to find it -- then it knows what's going on. I'd suggest we maintain the status quo. -- Vitaly
