Adds a new CPU flag to enable the Enlightened VMCS KVM feature.
QEMU enables KVM_CAP_HYPERV_ENLIGHTENED_VMCS and gets back the
version to be advertised in lower 16 bits of CPUID.0x4000000A:EAX.
Suggested-by: Ladi Prosek <lprosek@redhat.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
target/i386/cpu.c | 1 +
target/i386/cpu.h | 1 +
target/i386/hyperv-proto.h | 3 +++
target/i386/kvm.c | 20 ++++++++++++++++++--
4 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index c88876dfe3..5c0e84fb99 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -5564,6 +5564,7 @@ static Property x86_cpu_properties[] = {
DEFINE_PROP_BOOL("hv-frequencies", X86CPU, hyperv_frequencies, false),
DEFINE_PROP_BOOL("hv-reenlightenment", X86CPU, hyperv_reenlightenment, false),
DEFINE_PROP_BOOL("hv-tlbflush", X86CPU, hyperv_tlbflush, false),
+ DEFINE_PROP_BOOL("hv-evmcs", X86CPU, hyperv_evmcs, false),
DEFINE_PROP_BOOL("check", X86CPU, check_cpuid, true),
DEFINE_PROP_BOOL("enforce", X86CPU, enforce_cpuid, false),
DEFINE_PROP_BOOL("kvm", X86CPU, expose_kvm, true),
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 730c06f80a..013d953b57 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1382,6 +1382,7 @@ struct X86CPU {
bool hyperv_frequencies;
bool hyperv_reenlightenment;
bool hyperv_tlbflush;
+ bool hyperv_evmcs;
bool check_cpuid;
bool enforce_cpuid;
bool expose_kvm;
diff --git a/target/i386/hyperv-proto.h b/target/i386/hyperv-proto.h
index d6d5a79293..fcb0c416f8 100644
--- a/target/i386/hyperv-proto.h
+++ b/target/i386/hyperv-proto.h
@@ -18,7 +18,9 @@
#define HV_CPUID_FEATURES 0x40000003
#define HV_CPUID_ENLIGHTMENT_INFO 0x40000004
#define HV_CPUID_IMPLEMENT_LIMITS 0x40000005
+#define HV_CPUID_NESTED_FEATURES 0x4000000A
#define HV_CPUID_MIN 0x40000005
+#define HV_CPUID_MIN_NESTED 0x4000000A
#define HV_CPUID_MAX 0x4000ffff
#define HV_HYPERVISOR_PRESENT_BIT 0x80000000
@@ -59,6 +61,7 @@
#define HV_SYSTEM_RESET_RECOMMENDED (1u << 4)
#define HV_RELAXED_TIMING_RECOMMENDED (1u << 5)
#define HV_EX_PROCESSOR_MASKS_RECOMMENDED (1u << 11)
+#define HV_ENLIGHTENED_VMCS_RECOMMENDED (1u << 14)
/*
* Basic virtualized MSRs
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index a46ad102d8..8e383e7197 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -798,6 +798,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
uint32_t unused;
struct kvm_cpuid_entry2 *c;
uint32_t signature[3];
+ uint16_t evmcs_version;
int kvm_base = KVM_CPUID_SIGNATURE;
int r;
Error *local_err = NULL;
@@ -841,7 +842,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
memset(signature, 0, 12);
memcpy(signature, cpu->hyperv_vendor_id, len);
}
- c->eax = HV_CPUID_MIN;
+ c->eax = cpu->hyperv_evmcs ? HV_CPUID_MIN_NESTED : HV_CPUID_MIN;
c->ebx = signature[0];
c->ecx = signature[1];
c->edx = signature[2];
@@ -888,7 +889,16 @@ int kvm_arch_init_vcpu(CPUState *cs)
c->eax |= HV_REMOTE_TLB_FLUSH_RECOMMENDED;
c->eax |= HV_EX_PROCESSOR_MASKS_RECOMMENDED;
}
-
+ if (cpu->hyperv_evmcs) {
+ if (kvm_vcpu_enable_cap(cs, KVM_CAP_HYPERV_ENLIGHTENED_VMCS, 0,
+ (uintptr_t)&evmcs_version)) {
+ fprintf(stderr, "Hyper-V Enlightened VMCS "
+ "(requested by 'hv-evmcs' cpu flag) "
+ "is not supported by kernel\n");
+ return -ENOSYS;
+ }
+ c->eax |= HV_ENLIGHTENED_VMCS_RECOMMENDED;
+ }
c->ebx = cpu->hyperv_spinlock_attempts;
c = &cpuid_data.entries[cpuid_i++];
@@ -899,6 +909,12 @@ int kvm_arch_init_vcpu(CPUState *cs)
kvm_base = KVM_CPUID_SIGNATURE_NEXT;
has_msr_hv_hypercall = true;
+
+ if (cpu->hyperv_evmcs) {
+ c = &cpuid_data.entries[cpuid_i++];
+ c->function = HV_CPUID_NESTED_FEATURES;
+ c->eax = evmcs_version;
+ }
}
if (cpu->expose_kvm) {
--
2.17.2
On Fri, Oct 19, 2018 at 01:14:32PM +0200, Vitaly Kuznetsov wrote:
> --- a/target/i386/kvm.c
> +++ b/target/i386/kvm.c
> @@ -798,6 +798,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
> uint32_t unused;
> struct kvm_cpuid_entry2 *c;
> uint32_t signature[3];
> + uint16_t evmcs_version;
> int kvm_base = KVM_CPUID_SIGNATURE;
> int r;
> Error *local_err = NULL;
> @@ -841,7 +842,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
> memset(signature, 0, 12);
> memcpy(signature, cpu->hyperv_vendor_id, len);
> }
> - c->eax = HV_CPUID_MIN;
> + c->eax = cpu->hyperv_evmcs ? HV_CPUID_MIN_NESTED : HV_CPUID_MIN;
I think these two aren't meant to be used on the hypervisor side. My
understanding is that HV_CPUID_MIN is only there as a reminder that the
real Hyper-V exposes at least that many hypervisor-specific leaves so
the guest can rely on that. So I'd rather use directly
HV_CPUID_IMPLEMENT_LIMITS : HV_CPUID_NESTED_FEATURES, and not introduce
HV_CPUID_MIN_NESTED. Maybe better yet is to update this field with the
maximum value while populating HV_* leaves:
if (hyperv_enabled(cpu)) {
uint32_t *cpuid_40000000_eax;
c = &cpuid_data.entries[cpuid_i++];
c->function = HV_CPUID_VENDOR_AND_MAX_FUNCTIONS;
cpuid_40000000_eax = &c->eax;
*cpuid_40000000_eax = c->function;
....
c = &cpuid_data.entries[cpuid_i++];
c->function = HV_CPUID_...;
*cpuid_40000000_eax = max(*cpuid_40000000_eax, c->function);
but I think it can be done later and doesn't need to hold this patch.
Another question related to this: are the guests OK with leaves
0x40000006..0x40000009 missing?
Thanks,
Roman.
Roman Kagan <rkagan@virtuozzo.com> writes:
> On Fri, Oct 19, 2018 at 01:14:32PM +0200, Vitaly Kuznetsov wrote:
>> --- a/target/i386/kvm.c
>> +++ b/target/i386/kvm.c
>> @@ -798,6 +798,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
>> uint32_t unused;
>> struct kvm_cpuid_entry2 *c;
>> uint32_t signature[3];
>> + uint16_t evmcs_version;
>> int kvm_base = KVM_CPUID_SIGNATURE;
>> int r;
>> Error *local_err = NULL;
>> @@ -841,7 +842,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
>> memset(signature, 0, 12);
>> memcpy(signature, cpu->hyperv_vendor_id, len);
>> }
>> - c->eax = HV_CPUID_MIN;
>> + c->eax = cpu->hyperv_evmcs ? HV_CPUID_MIN_NESTED : HV_CPUID_MIN;
>
>
> I think these two aren't meant to be used on the hypervisor side. My
> understanding is that HV_CPUID_MIN is only there as a reminder that the
> real Hyper-V exposes at least that many hypervisor-specific leaves so
> the guest can rely on that. So I'd rather use directly
> HV_CPUID_IMPLEMENT_LIMITS : HV_CPUID_NESTED_FEATURES, and not introduce
> HV_CPUID_MIN_NESTED.
Makes sense, will do v2.
> Maybe better yet is to update this field with the
> maximum value while populating HV_* leaves:
>
> if (hyperv_enabled(cpu)) {
> uint32_t *cpuid_40000000_eax;
> c = &cpuid_data.entries[cpuid_i++];
> c->function = HV_CPUID_VENDOR_AND_MAX_FUNCTIONS;
> cpuid_40000000_eax = &c->eax;
> *cpuid_40000000_eax = c->function;
>
> ....
>
> c = &cpuid_data.entries[cpuid_i++];
> c->function = HV_CPUID_...;
> *cpuid_40000000_eax = max(*cpuid_40000000_eax, c->function);
>
> but I think it can be done later and doesn't need to hold this patch.
>
> Another question related to this: are the guests OK with leaves
> 0x40000006..0x40000009 missing?
They seem to be, however, after you've asked I'm leaning towards zeroing
them 'just in case'.
--
Vitaly
© 2016 - 2026 Red Hat, Inc.