converted to using raw CPUID func/reg
pairs for features, this allows us to get rid of hv_cpuid_get_fw()
conversion.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 90 +--
target/i386/cpu.h | 5 --
target/i386/kvm/kvm.c | 108 ++---
As a preparatory patch to dropping Hyper-V CPUID leaves from
feature_word_info[] stop using env->features[] as a temporary
storage of Hyper-V CPUIDs, just build Hyper-V CPUID leaves directly
from kvm_hyperv_properties[] data.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.h |
guest but arguably this is a good change.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index afd173514da1..7c751185491f 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386
7;s query-cpu-model-expansion output
is incorrect.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 19 +--
target/i386/kvm/kvm.c | 5 +
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index ad99cad0e7ce..2d05
KVM_GET_SUPPORTED_HV_CPUID was made a system wide ioctl which can be called
prior to creating vCPUs and we are going to use that to expand Hyper-V cpu
features early. Use it when it is supported by KVM.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 17 +
1 file
As a preparation to implementing hv_cpuid_cache intro introduce
hv_cpuid_get_host(). No functional change intended.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 102 +++---
1 file changed, 57 insertions(+), 45 deletions(-)
diff --git a/target
ote, hv_cpuid_get_fw() is converted to using hv_cpuid_get_host()
just to be removed later with Hyper-V specific feature words.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 109 ++
1 file changed, 56 insertions(+), 53 deletions(-)
diff --git a/target/i386/
There is no need to have this special case: like all other Hyper-V
enlightenments we can just use kernel's supplied value in hv_passthrough
mode.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/target/i38
Clean up hv_cpuid_check_and_set() by separating hyperv_feature_supported()
off it. No functional change intended.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 49 ++-
1 file changed, 30 insertions(+), 19 deletions(-)
diff --git a/target
Use standard error_setg() mechanism in hyperv_expand_features().
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 101 +-
1 file changed, 61 insertions(+), 40 deletions(-)
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index
it. Also, in 'passthrough' mode we don't really need to
check dependencies because KVM is supposed to provide a consistent
set anyway.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 105 +++---
1 file changed, 36 insertions(+), 69 delet
The intention is to call hyperv_expand_features() early, before vCPUs
are created and use the acquired data later when we set guest visible
CPUID data.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 34 --
1 file changed, 24 insertions(+), 10
observed. We may,
however, want to tighten the checks eventually. Conforming to the
spec is probably also a good idea.
Add HV_HYPERCALL_AVAILABLE to all 'leaf' features with no dependencies.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 15 +--
1 file changed, 9
hyperv_expand_features() will be called before we create vCPU so
evmcs enablement should go away. hyperv_init_vcpu() looks like the
right place.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 60 ++-
1 file changed, 37 insertions(+), 23
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/hyperv-proto.h | 6 ++
target/i386/kvm/kvm.c | 5 +
2 files changed, 11 insertions(+)
diff --git a/target/i386/kvm/hyperv-proto.h b/target/i386/kvm/hyperv-proto.h
index e30d64b4ade4..5fbb385cc136 100644
--- a/target/i386/
For the beginning, just test 'hv-passthrough' and a couple of custom
Hyper-V enlightenments configurations through QMP. Later, it would
be great to complement this by checking CPUID values from within the
guest.
Signed-off-by: Vitaly Kuznetsov
---
MAINTAINERS | 1 +
t
SYNDBG leaves were recently (Linux-5.8) added to KVM but we haven't
updated the expected size of KVM_GET_SUPPORTED_HV_CPUID output in
KVM so we now make serveral tries before succeeding. Update the
default.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 3 ++-
1 file chang
can't use kvm_arch_get_supported_cpuid()
as Hyper-V specific CPUID leaves intersect with KVM's.
Note, early expansion will only happen when KVM supports system wide
KVM_GET_SUPPORTED_HV_CPUID ioctl (KVM_CAP_SYS_HYPERV_CPUID).
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c
There is no need to use vCPU-specific kvm state in hyperv_enabled() check
and we need to do that when feature expansion happens early, before vCPU
specific KVM state is created.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions
Vitaly Kuznetsov writes:
> Igor Mammedov writes:
>
>>>
>>> We need to distinguish because that would be sane.
>>>
>>> Enlightened VMCS is an extension to VMX, it can't be used without
>>> it. Genuine Hyper-V doesn't have a knob
Igor Mammedov writes:
> On Mon, 22 Feb 2021 11:20:34 +0100
> Vitaly Kuznetsov wrote:
>
>> Vitaly Kuznetsov writes:
>>
>> > Igor Mammedov writes:
>> >
>> >>>
>> >>> We need to distinguish because that would be sane.
>
Igor Mammedov writes:
> On Tue, 23 Feb 2021 16:46:50 +0100
> Vitaly Kuznetsov wrote:
>
>> Igor Mammedov writes:
>>
>> > On Mon, 22 Feb 2021 11:20:34 +0100
>> > Vitaly Kuznetsov wrote:
>> >
>> >> Vita
Igor Mammedov writes:
> On Tue, 23 Feb 2021 19:08:42 +0100
> Vitaly Kuznetsov wrote:
>
>> Igor Mammedov writes:
>>
>> > On Tue, 23 Feb 2021 16:46:50 +0100
>> > Vitaly Kuznetsov wrote:
>> >
>> >> Igor Mammedov writes:
>&g
ne, we can make early Hyper-V feature expansion (this series).
In addition, provide a simple 'hv-default' option which enables (and
requires from KVM) all currently supported Hyper-V enlightenments except
for 'hv-evmcs' (for now). Unlike 'hv-passthrough' mode, thi
guest but arguably this is a good change.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 3c1202333d9d..1b1934362a89 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386
As a preparatory patch to dropping Hyper-V CPUID leaves from
feature_word_info[] stop using env->features[] as a temporary
storage of Hyper-V CPUIDs, just build Hyper-V CPUID leaves directly
from kvm_hyperv_properties[] data.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.h |
Clean up hv_cpuid_check_and_set() by separating hyperv_feature_supported()
off it. No functional change intended.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 49 ++-
1 file changed, 30 insertions(+), 19 deletions(-)
diff --git a/target
7;s query-cpu-model-expansion output
is incorrect.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 19 +--
target/i386/kvm/kvm.c | 5 +
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 6a53446e6a56..ee09
The intention is to call hyperv_expand_features() early, before vCPUs
are created and use the acquired data later when we set guest visible
CPUID data.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 34 --
1 file changed, 24 insertions(+), 10
As a preparation to implementing hv_cpuid_cache intro introduce
hv_cpuid_get_host(). No functional change intended.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 102 +++---
1 file changed, 57 insertions(+), 45 deletions(-)
diff --git a/target
converted to using raw CPUID func/reg
pairs for features, this allows us to get rid of hv_cpuid_get_fw()
conversion.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 90 +--
target/i386/cpu.h | 5 --
target/i386/kvm/kvm.c | 108 ++---
There is no need to have this special case: like all other Hyper-V
enlightenments we can just use kernel's supplied value in hv_passthrough
mode.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/target/i38
hyperv_expand_features() will be called before we create vCPU so
evmcs enablement should go away. hyperv_init_vcpu() looks like the
right place.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 60 ++-
1 file changed, 37 insertions(+), 23
SYNDBG leaves were recently (Linux-5.8) added to KVM but we haven't
updated the expected size of KVM_GET_SUPPORTED_HV_CPUID output in
KVM so we now make serveral tries before succeeding. Update the
default.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 3 ++-
1 file chang
ote, hv_cpuid_get_fw() is converted to using hv_cpuid_get_host()
just to be removed later with Hyper-V specific feature words.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 109 ++
1 file changed, 56 insertions(+), 53 deletions(-)
diff --git a/target/i386/
KVM_GET_SUPPORTED_HV_CPUID was made a system wide ioctl which can be called
prior to creating vCPUs and we are going to use that to expand Hyper-V cpu
features early. Use it when it is supported by KVM.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 17 +
1 file
Use standard error_setg() mechanism in hyperv_expand_features().
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 101 +-
1 file changed, 61 insertions(+), 40 deletions(-)
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index
There is no need to use vCPU-specific kvm state in hyperv_enabled() check
and we need to do that when feature expansion happens early, before vCPU
specific KVM state is created.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions
tion.
Introduce a simple 'hv-default=on' CPU flag enabling all currently supported
Hyper-V enlightenments. Later, when new enlightenments get implemented,
compat_props mechanism will be used to disable them for legacy machine types,
this will keep 'hv-default=on' configurations
can't use kvm_arch_get_supported_cpuid()
as Hyper-V specific CPUID leaves intersect with KVM's.
Note, early expansion will only happen when KVM supports system wide
KVM_GET_SUPPORTED_HV_CPUID ioctl (KVM_CAP_SYS_HYPERV_CPUID).
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c
For the beginning, just test 'hv-default', 'hv-passthrough' and a couple
of custom Hyper-V enlightenments configurations through QMP. Later, it
would be great to complement this by checking CPUID values from within the
guest.
Signed-off-by: Vitaly Kuznetsov
---
MAINTAINERS
Igor Mammedov writes:
> On Wed, 24 Feb 2021 18:00:43 +0100
> Vitaly Kuznetsov wrote:
>
>> Igor Mammedov writes:
>>
>> > On Tue, 23 Feb 2021 19:08:42 +0100
>> > Vitaly Kuznetsov wrote:
>> >
>> >> Igor Mammedov writes:
>&g
KVM_CAP_SYS_HYPERV_CPUID definition is needed for this series.
Signed-off-by: Vitaly Kuznetsov
---
linux-headers/asm-x86/kvm.h | 20
linux-headers/linux/kvm.h | 27 ---
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/linux-headers
We only use x86_cpu_get_supported_feature_word() after its implementation,
no forward declaration needed.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index f37eb7b675f4..bbfdfb8a3f88 100644
There was a typo which went unnoticed.
Fixes: e48ddcc6ce13 ("i386/kvm: implement 'hv-passthrough' mode")
Signed-off-by: Vitaly Kuznetsov
---
- Similar fix h
As a preparation to expanding Hyper-V CPU features early, move
hyperv_interface_id initialization to x86_cpu_realizefn().
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 6 ++
target/i386/cpu.h | 1 +
target/i386/kvm.c | 18 --
3 files changed, 19 insertions(+), 6
As a preparation to expanding Hyper-V CPU features early, move
hyperv_vendor_id initialization to x86_cpu_realizefn(). Introduce
x86_cpu_hyperv_realize() to not not pollute x86_cpu_realizefn()
itself.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 23 ++-
target
guest but arguably this is a good change.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 5350cd867759..56bfc8da85d0 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -1206,9 +1206,6
As a preparation to expanding Hyper-V CPU features early, move
hyperv_version_id initialization to x86_cpu_realizefn().
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 4
target/i386/cpu.h | 1 +
target/i386/kvm.c | 14 --
3 files changed, 17 insertions(+), 2
Hyper-V feature expansion (this series).
In addition, add a simple 'hyperv=on' option to x86 machine types which
enables (and requires from KVM) all currently supported Hyper-V enlightenments.
Unlike 'hv_passthrough' mode, this is going to be migratable.
Vitaly Ku
As a preparation to expanding Hyper-V CPU features early, move
hyperv_limits initialization to x86_cpu_realizefn().
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 5 +
target/i386/cpu.h | 1 +
target/i386/kvm.c | 13 -
3 files changed, 18 insertions(+), 1 deletion
Clean up hv_cpuid_check_and_set() by separating hyperv_feature_supported()
off it. No functional change intended.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 49 +--
1 file changed, 30 insertions(+), 19 deletions(-)
diff --git a/target
As a preparation to implementing hv_cpuid_cache intro introduce
hv_cpuid_get_host(). No functional change intended.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 100 ++
1 file changed, 56 insertions(+), 44 deletions(-)
diff --git a/target
7;s query-cpu-model-expansion output
is incorrect.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 20 ++--
target/i386/kvm.c | 4
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 45644f063947..c12d539389
As a preparatory patch to dropping Hyper-V CPUID leaves from
feature_word_info[] stop using env->features[] as a temporary
storage of Hyper-V CPUIDs, just build Hyper-V CPUID leaves directly
from kvm_hyperv_properties[] data.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.h | 1 +
tar
ote, hv_cpuid_get_fw() is converted to using hv_cpuid_get_host()
just to be removed later with Hyper-V specific feature words.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 109 --
1 file changed, 56 insertions(+), 53 deletions(-)
diff --git a/target/i
There is no need to have this special case: like all other Hyper-V
enlightenments we can just use kernel's supplied value in hv_passthrough
mode.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/target/i386/kv
SYNDBG leaves were recently (Linux-5.8) added to KVM but we haven't
updated the expected size of KVM_GET_SUPPORTED_HV_CPUID output in
KVM so we now make serveral tries before succeeding. Update the
default.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 3 ++-
1 file chang
There is no need to use vCPU-specific kvm state in hyperv_enabled() check
and we need to do that when feature expansion happens early, before vCPU
specific KVM state is created.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
converted to using raw CPUID func/reg
pairs for features, this allows us to get rid of hv_cpuid_get_fw()
conversion.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 90 +-
target/i386/cpu.h | 5 ---
target/i386/kvm.c | 108 -
hyperv_expand_features() will be called before we create vCPU so
evmcs enablement should go away. hyperv_init_vcpu() looks like the
right place.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 60 +--
1 file changed, 37 insertions(+), 23
can't use kvm_arch_get_supported_cpuid()
as Hyper-V specific CPUID leaves intersect with KVM's.
Note, early expansion will only happen when KVM supports system wide
KVM_GET_SUPPORTED_HV_CPUID ioctl (KVM_CAP_SYS_HYPERV_CPUID).
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c
The intention is to call hyperv_expand_features() early, before vCPUs
are created and use the acquired data later when we set guest visible
CPUID data.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 34 --
1 file changed, 24 insertions(+), 10 deletions
Use standard error_setg() mechanism in hyperv_expand_features().
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 101 --
1 file changed, 61 insertions(+), 40 deletions(-)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 06f78a09304e
KVM_GET_SUPPORTED_HV_CPUID was made a system wide ioctl which can be called
prior to creating vCPUs and we are going to use that to expand Hyper-V cpu
features early. Use it when it is supported by KVM.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 17 +
1 file changed
tion.
Introduce a simple 'hyperv=on' option for all x86 machine types enabling
all currently supported Hyper-V enlightenments. Later, when new
enlightenments get implemented, we will be adding them to newer machine
types only (by disabling them for legacy machine types) thus preservin
Igor Mammedov writes:
> On Thu, 21 Jan 2021 09:45:33 +0100
> Vitaly Kuznetsov wrote:
>
>> >
>> > So far I read snippet above as a problem:
>> > 1:
>> > host supports evmcs:
>> > and exposes HYPERV_FEAT_EVMCS in CPUID
>>
>&g
ansaction in one shot but as a band-aid we can
just pause all vCPUs to make memory transations atomic.
Reported-by: Dr. David Alan Gilbert
Signed-off-by: Vitaly Kuznetsov
---
RFC: Generally, memap updates happen only a few times during guest boot but
I'm not sure there are no scena
David Hildenbrand writes:
> On 26.10.20 11:43, David Hildenbrand wrote:
>> On 26.10.20 09:49, Vitaly Kuznetsov wrote:
>>> Currently, KVM doesn't provide an API to make atomic updates to memmap when
>>> the change touches more than one memory slot, e.g. in case we&
David Hildenbrand writes:
> On 27.10.20 14:02, Vitaly Kuznetsov wrote:
>>
>> Sorry for not being clear: your patch looks good to me, what I tried to
>> say is that with the current KVM API the only way to guarantee atomicity
>> of the update is to make vCPUs stop (o
David Hildenbrand writes:
> On 27.10.20 13:36, Vitaly Kuznetsov wrote:
>> David Hildenbrand writes:
>>
>>> On 26.10.20 11:43, David Hildenbrand wrote:
>>>> On 26.10.20 09:49, Vitaly Kuznetsov wrote:
>>>>> Currently, KVM doesn't pro
David Hildenbrand writes:
>>> Same applies to all other kinds of operations (splitting, punching out,
>>> ...) as you also mentioned.
>>
>> One question from a QEMU newbie though: why do you put
>> kvm_ioctl_inhibit_begin()/kvm_ioctl_inhibit_end() to kvm_region_resize()
>> only and not taking it
There is no need to have this special case: like all other Hyper-V
enlightenments we can just use kernel's supplied value in hv_passthrough
mode.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/target/i38
is what KVM part does. With
that done, we can make early Hyper-V feature expansion (this series).
In addition, provide a simple 'hv-default' option which enables (and
requires from KVM) all currently supported Hyper-V enlightenments.
Unlike 'hv-passthrough' mode, this is going to
converted to using raw CPUID func/reg
pairs for features, this allows us to get rid of hv_cpuid_get_fw()
conversion.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 90 +--
target/i386/cpu.h | 5 --
target/i386/kvm/kvm.c | 108 ++---
As a preparatory patch to dropping Hyper-V CPUID leaves from
feature_word_info[] stop using env->features[] as a temporary
storage of Hyper-V CPUIDs, just build Hyper-V CPUID leaves directly
from kvm_hyperv_properties[] data.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.h |
hyperv_expand_features() will be called before we create vCPU so
evmcs enablement should go away. hyperv_init_vcpu() looks like the
right place.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 60 ++-
1 file changed, 37 insertions(+), 23
guest but arguably this is a good change.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 211efbd13b49..ba285a364792 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386
ote, hv_cpuid_get_fw() is converted to using hv_cpuid_get_host()
just to be removed later with Hyper-V specific feature words.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 109 ++
1 file changed, 56 insertions(+), 53 deletions(-)
diff --git a/target/i386/
Clean up hv_cpuid_check_and_set() by separating hyperv_feature_supported()
off it. No functional change intended.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 49 ++-
1 file changed, 30 insertions(+), 19 deletions(-)
diff --git a/target
7;s query-cpu-model-expansion output
is incorrect.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 19 +--
target/i386/kvm/kvm.c | 4
2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 9c3d2d60b7e5..d03c
ation time when 'hv-passthrough' is specified and we're running on
an older kernel without KVM_CAP_SYS_HYPERV_CPUID support. To get the list
of the supported Hyper-V features we need to actually create KVM VCPU and
this happens much later.
No
As a preparation to implementing hv_cpuid_cache intro introduce
hv_cpuid_get_host(). No functional change intended.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 100 +++---
1 file changed, 56 insertions(+), 44 deletions(-)
diff --git a/target
KVM_GET_SUPPORTED_HV_CPUID was made a system wide ioctl which can be called
prior to creating vCPUs and we are going to use that to expand Hyper-V cpu
features early. Use it when it is supported by KVM.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 17 +
1 file
can't use kvm_arch_get_supported_cpuid()
as Hyper-V specific CPUID leaves intersect with KVM's.
Note, early expansion will only happen when KVM supports system wide
KVM_GET_SUPPORTED_HV_CPUID ioctl (KVM_CAP_SYS_HYPERV_CPUID).
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c
The intention is to call hyperv_expand_features() early, before vCPUs
are created and use the acquired data later when we set guest visible
CPUID data.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 34 --
1 file changed, 24 insertions(+), 10
SYNDBG leaves were recently (Linux-5.8) added to KVM but we haven't
updated the expected size of KVM_GET_SUPPORTED_HV_CPUID output in
KVM so we now make serveral tries before succeeding. Update the
default.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 3 ++-
1 file chang
For the beginning, just test 'hv-default', 'hv-passthrough' and a couple
of custom Hyper-V enlightenments configurations through QMP. Later, it
would be great to complement this by checking CPUID values from within the
guest.
Signed-off-by: Vitaly Kuznetsov
---
MAINTAINERS
Use standard error_setg() mechanism in hyperv_expand_features().
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 101 +-
1 file changed, 61 insertions(+), 40 deletions(-)
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index
ently, the
only possible scenario is 'hv-passthrough' which will enable 'hv-evmcs'
when the host supports it, regardless of guest VMX exposure. The upcoming
'hv-default' should also avoid enabling 'hv-evmcs' without VMX.
Signed-off-by: Vitaly Kuznetsov
---
targe
tion.
Introduce a simple 'hv-default=on' CPU flag enabling all currently supported
Hyper-V enlightenments. Later, when new enlightenments get implemented,
compat_props mechanism will be used to disable them for legacy machine types,
this will keep 'hv-default=on' configurations
There is no need to use vCPU-specific kvm state in hyperv_enabled() check
and we need to do that when feature expansion happens early, before vCPU
specific KVM state is created.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions
ure".
While on it, make 'hv-passthrough' parse semantics in-line with other
options in qemu: when specified, it overrides what was previously set with
what's supported by the host. This can later be modified with 'hv-feature=on'/
'hv-feat
Enlightened VMCS feature is hardware specific, it is only supported on
Intel CPUs. Introduce a simple kvm_hv_evmcs_available() helper, it will
be used to filter out 'hv_evmcs' when 'hyperv=on' option is added to
X86MachineClass.
Signed-off-by: Vitaly Kuznetsov
---
target/i38
Eduardo Habkost writes:
> On Wed, Feb 10, 2021 at 04:56:06PM +, Daniel P. Berrangé wrote:
>> On Wed, Feb 10, 2021 at 05:40:12PM +0100, Vitaly Kuznetsov wrote:
>> > Changes since v3:
>> > - Make 'hv-default' override 'hv-*' options which w
Daniel P. Berrangé writes:
> On Thu, Feb 11, 2021 at 09:30:53AM +0100, Vitaly Kuznetsov wrote:
>> Eduardo Habkost writes:
>>
>> > On Wed, Feb 10, 2021 at 04:56:06PM +, Daniel P. Berrangé wrote:
>> >> On Wed, Feb 10, 2021 at 05:40:12PM +0100, Vitaly Kuzne
Igor Mammedov writes:
> On Wed, 10 Feb 2021 17:40:28 +0100
> Vitaly Kuznetsov wrote:
>
>> Sometimes we'd like to know which features were explicitly enabled and which
>> were explicitly disabled on the command line. E.g. it seems logical to handle
>> 'hv_p
Igor Mammedov writes:
> On Wed, 10 Feb 2021 17:40:29 +0100
> Vitaly Kuznetsov wrote:
>
>> Currently, we support 'hv-passthrough,hv-feature=on' enablement, this
>> is supposed to mean "hv-feature is mandatory, don't start without it". Add
>>
Igor Mammedov writes:
> On Wed, 10 Feb 2021 17:40:32 +0100
> Vitaly Kuznetsov wrote:
>
>> Enabling Hyper-V emulation for a Windows VM is a tiring experience as it
>> requires listing all currently supported enlightenments ("hv-*" CPU
>> features) explici
Igor Mammedov writes:
> On Fri, 12 Feb 2021 09:45:52 +0100
> Vitaly Kuznetsov wrote:
>
>> Igor Mammedov writes:
>>
>> > On Wed, 10 Feb 2021 17:40:28 +0100
>> > Vitaly Kuznetsov wrote:
>> >
>> >> Sometimes we'd like to know w
201 - 300 of 529 matches
Mail list logo
