Liang Li writes:
> [resend for missing cc]
>
> Hi Vitaly,
>
> I found a case that the virtualization overhead was almost doubled
> when turning on Hper-v related features compared to that without any
> no hyper-v feature. It happens when running a 3D game in windows
> guest in qemu kvm
Eduardo Habkost writes:
> On Thu, Apr 22, 2021 at 06:11:12PM +0200, Vitaly Kuznetsov wrote:
>> When cpu->hyperv_vendor is not set manually we default to "Microsoft Hv"
>> and in 'hv_passthrough' mode we get the information from the host. This
>> information
Liang Li writes:
>> >> > Analyze events for all VMs, all VCPUs:
>> >> > VM-EXITSamples Samples% Time%Min TimeMax
>> >> > Time Avg time
>> >> > EXTERNAL_INTERRUPT 47183159.89%68.58% 0.64us
>> >> > 65.42us 2.34us ( +- 0.11% )
>> >> >
Eduardo Habkost writes:
> On Fri, Jun 04, 2021 at 09:28:15AM +0200, Vitaly Kuznetsov wrote:
>> Eduardo Habkost writes:
>>
>> > On Thu, Jun 03, 2021 at 01:48:29PM +0200, Vitaly Kuznetsov wrote:
>> >> Currently, the only eVMCS version, supported by KVM (and d
Eduardo Habkost writes:
>>
>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>> index 9e211ac2ce..6bcb7dbc2c 100644
>> --- a/target/i386/cpu.c
>> +++ b/target/i386/cpu.c
>> @@ -6133,34 +6133,6 @@ static void x86_cpu_realizefn(DeviceState *dev, Error
>> **errp)
>> Error *local_err =
-evmcs=2').
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt | 2 +-
target/i386/kvm/kvm.c | 16 +++-
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/docs/hyperv.txt b/docs/hyperv.txt
index a51953daa833..000638a2fd38 100644
--- a/docs/hyperv.txt
+++ b/docs
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 +
tests/qtest
lso, in 'passthrough' mode we don't really need to
check dependencies because KVM is supposed to provide a consistent
set anyway.
Reviewed-by: Eduardo Habkost
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 104 +++---
1 file changed, 36 insertions(+),
When Hyper-V SynIC is enabled, we may need to allow Windows guests to make
hypercalls (POST_MESSAGES/SIGNAL_EVENTS). No issue is currently observed
because KVM is very permissive, allowing these hypercalls regarding of
guest visible CPUid bits.
Signed-off-by: Vitaly Kuznetsov
---
target/i386
is observed. We may,
however, want to tighten the checks eventually. Conforming to the
spec is probably also a good idea.
Enable HV_HYPERCALL_AVAILABLE bit unconditionally.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff
Clarify the fact that 'hv-passthrough' only enables features which are
already known to QEMU and that it overrides all other 'hv-*' settings.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/docs/hyperv.txt b/docs
While this is very unlikely to change, let's avoid hardcoding '12' as
'hyperv_vendor_id' length.
No functional change intended.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386
Return 'false' when hyperv_expand_features() sets an error.
No functional change intended.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 40 +---
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/target/i386/kvm/kvm.c b/target
y Hyper-V feature expansion (this series).
Vitaly Kuznetsov (9):
i386: avoid hardcoding '12' as 'hyperv_vendor_id' length
i386: clarify 'hv-passthrough' behavior
i386: hardcode supported eVMCS version to '1'
i386: make hyperv_expand_features() return bool
i386: expand Hyper-V features
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 | 4
Eduardo Habkost writes:
> On Thu, Jun 03, 2021 at 01:48:29PM +0200, Vitaly Kuznetsov wrote:
>> Currently, the only eVMCS version, supported by KVM (and described in TLFS)
>> is '1'. When Enlightened VMCS feature is enabled, QEMU takes the supported
>> eVMC
Eduardo Habkost writes:
> On Thu, Jun 03, 2021 at 01:48:34PM +0200, Vitaly Kuznetsov wrote:
>> When Hyper-V SynIC is enabled, we may need to allow Windows guests to make
>> hypercalls (POST_MESSAGES/SIGNAL_EVENTS). No issue is currently observed
>> because KVM is very
Eduardo Habkost writes:
> On Thu, Jun 03, 2021 at 01:48:31PM +0200, Vitaly Kuznetsov wrote:
>> To make Hyper-V features appear in e.g. QMP query-cpu-model-expansion we
>> need to expand and set the corresponding CPUID leaves early. Modify
>> x86_cpu_get_supported_feature
Eduardo Habkost writes:
> On Thu, Jun 03, 2021 at 01:48:35PM +0200, Vitaly Kuznetsov wrote:
>> 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 check
Eduardo Habkost writes:
> On Mon, May 24, 2021 at 02:22:47PM +0200, Vitaly Kuznetsov wrote:
>> Eduardo Habkost writes:
>>
>> > On Thu, Apr 22, 2021 at 06:11:28PM +0200, Vitaly Kuznetsov wrote:
>> >> According to TLFS, Hyper-V guest is supposed to check
&g
Eduardo Habkost writes:
> On Thu, Apr 22, 2021 at 06:11:11PM +0200, Vitaly Kuznetsov wrote:
>> Vitaly Kuznetsov (19):
>> i386: keep hyperv_vendor string up-to-date
>> i386: invert hyperv_spinlock_attempts setting logic with
>> hv_passthrough
>> i386:
Eduardo Habkost writes:
> On Mon, May 24, 2021 at 02:00:37PM +0200, Vitaly Kuznetsov wrote:
> [...]
>> >> @@ -1455,6 +1454,21 @@ static int hyperv_init_vcpu(X86CPU *cpu)
>> >> }
>> >> }
>> >>
>> >> +if (hype
Eduardo Habkost writes:
> On Mon, May 24, 2021 at 02:13:09PM +0200, Vitaly Kuznetsov wrote:
> [...]
>> >> diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
>> >> index a42263b24fca..d5551c4ab5cf 100644
>> >> --- a/target/i386/kvm/kvm.c
>>
Eduardo Habkost writes:
> On Thu, Apr 22, 2021 at 06:11:21PM +0200, Vitaly Kuznetsov wrote:
>> hyperv_expand_features() will be called before we create vCPU so
>> evmcs enablement should go away. hyperv_init_vcpu() looks like the
>> right place.
>>
>>
Eduardo Habkost writes:
> On Thu, Apr 22, 2021 at 06:11:26PM +0200, Vitaly Kuznetsov wrote:
>> To make Hyper-V features appear in e.g. QMP query-cpu-model-expansion we
>> need to expand and set the corresponding CPUID leaves early. Modify
>> x86_cpu_get_supported_feature
Eduardo Habkost writes:
> On Thu, Apr 22, 2021 at 06:11:28PM +0200, Vitaly Kuznetsov wrote:
>> According to TLFS, Hyper-V guest is supposed to check
>> HV_HYPERCALL_AVAILABLE privilege bit before accessing
>> HV_X64_MSR_GUEST_OS_ID/HV_X64_MSR_HYPERCALL MSRs but at least som
Eduardo Habkost writes:
> On Thu, Apr 22, 2021 at 06:11:24PM +0200, Vitaly Kuznetsov wrote:
>> 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
Eduardo Habkost writes:
> On Thu, Apr 22, 2021 at 06:11:27PM +0200, Vitaly Kuznetsov wrote:
>> hv_cpuid_check_and_set() does too much:
>> - Checks if the feature is supported by KVM;
>> - Checks if all dependencies are enabled;
>> - Sets the feature bit in cpu->hy
Eduardo Habkost writes:
> On Thu, Apr 22, 2021 at 06:11:22PM +0200, Vitaly Kuznetsov wrote:
>> Use standard error_setg() mechanism in hyperv_expand_features().
>>
>> Signed-off-by: Vitaly Kuznetsov
>
> No objections, but only suggestions below:
>
>>
d that early. This is what KVM part does. With
that done, we can make early Hyper-V feature expansion (this series).
Vitaly Kuznetsov (19):
i386: keep hyperv_vendor string up-to-date
i386: invert hyperv_spinlock_attempts setting logic with
hv_passthrough
i386: always fill Hyper-V CPUID feat
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 |
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/kvm/kvm.c
PUID 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 ++
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
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
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/i386/kvm
lso, 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 deletions(-)
diff --git a/tar
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
-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/kvm/hyperv
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 +
tests/qtest
el-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..2d05df232329 100644
---
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
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
is 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 insertions
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 changed, 2
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 | 4
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
PUID 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/i386/kvm
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 be migratable.
Vitaly Kuznetsov (21):
i386: keep hyperv_vendor string up-to-date
i386: invert hyperv_spinlock_attempts setting logic wi
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
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/kvm/kvm.c
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
el-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..d03c1588ba0e 100644
---
n
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 functional change intended.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/c
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 | 4
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 changed, 2
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 | 1
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
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
---
target/i386/kvm/kvm.c | 13 +++--
1 file changed, 11
e 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 migratable.
Signed-off-by: Vitaly
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
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-feature=off'.
Signed-off-by: Vitaly Kuznetsov
---
target
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/i386/kvm/kvm-stub.c | 5
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 were already set
>
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
fail late and
this may come as an unpleasant surprise. To make things more explicit,
require 'tsc-frequency=' on the command line when 'hv-reenlightenment' was
enabled. Make the change affect 6.0+ machine types only to preserve
previously-valid configurations valid.
Signed-off-by: Vitaly Kuznetsov
"Dr. David Alan Gilbert" writes:
> * Vitaly Kuznetsov (vkuzn...@redhat.com) wrote:
>> "Dr. David Alan Gilbert" writes:
>>
>> > * Vitaly Kuznetsov (vkuzn...@redhat.com) wrote:
>> >> KVM doesn't fully support Hyper-V reenlightenment not
"Dr. David Alan Gilbert" writes:
> * Vitaly Kuznetsov (vkuzn...@redhat.com) wrote:
>> KVM doesn't fully support Hyper-V reenlightenment notifications on
>> migration. In particular, it doesn't support emulating TSC frequency
>> of the source host by trapping
Just like all other KVM PV features, 'kvm-asyncpf-int' needs to be
added to all CPU models when KVM is enabled or the feature will always
remain 'off' unless specified explicitly on the command line.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 1 +
1 file changed, 1 insertion
migration.
This went unnoticed because of 1) I believe.
Vitaly Kuznetsov (2):
i386: Add 'kvm-asyncpf-int' to kvm_default_props array
i386: Disable 'kvm-asyncpf-int' feature for machine types <= 5.1
hw/i386/pc.c | 1 +
target/i386/cpu.c | 1 +
2 files changed, 2 insertions(+)
--
2.30.2
enabled.
Fixes: db5daafab2 ("target/i386: support KVM_FEATURE_ASYNC_PF_INT")
Signed-off-by: Vitaly Kuznetsov
---
hw/i386/pc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 8a84b25a031e..04d5f76bf133 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
fails late and
this may come as an unpleasant surprise. To make things more explicit,
require 'tsc-frequency=' on the command line when 'hv-reenlightenment' was
enabled. Make the change affect 6.0+ machine types only to preserve
previously-valid configurations.
Signed-off-by: Vitaly Kuznetsov
Ac
Paolo Bonzini writes:
> On 01/04/21 17:19, Vitaly Kuznetsov wrote:
>> I noticed two issues with 'kvm-asyncpf-int' enablement:
>> 1) We forgot to add to to kvm_default_props[] so it doesn't get enabled
>> automatically (unless '-cpu host' is used or the feature is
Claudio Fontana writes:
> On 11/19/20 11:32 AM, Vitaly Kuznetsov wrote:
>> 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_
env.tsc_khz packed in 'cpu/tsc_khz' but we don't want to be dependent
on the section order.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/hyperv.h | 1 +
target/i386/kvm/kvm.c| 11 +++
target/i386/machine.c| 37 +
3 files changed, 49 insertions
with migration.
Vitaly Kuznetsov (3):
i386: Make Hyper-V related sections KVM only
i386: Fix 'hypercall_hypercall' typo
i386: Make sure kvm_arch_set_tsc_khz() succeeds on migration when
'hv-reenlightenment' was exposed
target/i386/kvm/hyperv.h | 1 +
target/i386/kvm/kvm.c| 11
Even the name of this section is 'cpu/msr_hyperv_hypercall',
'hypercall_hypercall' is clearly a typo.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/machine.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/i386/machine.c b/target/i386/machine.c
index
Paolo Bonzini writes:
> On 18/03/21 17:02, Vitaly Kuznetsov wrote:
>> KVM doesn't fully support Hyper-V reenlightenment notifications on
>> migration. In particular, it doesn't support emulating TSC frequency
>> of the source host by trapping all TSC accesses
Currently, Hyper-V enlightenments are only implemented by KVM so there's no
need to have corresponding vmstate_x86_cpu sections when !CONFIG_KVM.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/machine.c | 4
1 file changed, 4 insertions(+)
diff --git a/target/i386/machine.c b/target/i386
Claudio Fontana writes:
> On 3/10/21 12:43 PM, Vitaly Kuznetsov wrote:
>> Claudio Fontana writes:
>>
>>> On 11/19/20 11:32 AM, Vitaly Kuznetsov wrote:
>>>> As a preparation to expanding Hyper-V CPU features early, move
>>>> hyperv_vendor_id
as we have to guarantee that TSC frequency stays constant.
Require 'tsc-frequency=' command line option to be specified for successful
migration when re-enlightenment was enabled by the guest.
Signed-off-by: Vitaly Kuznetsov
---
This patch is a successor of "[PATCH 3/3] i386: Make
Paolo Bonzini writes:
> On 18/03/21 17:38, Vitaly Kuznetsov wrote:
>>> Could we instead fail to load the reenlightenment section if
>>> user_tsc_khz was not set? This seems to be user (well, management)
>>> error really, since reenlightenment has to be en
Marcelo Tosatti writes:
> On Thu, Mar 18, 2021 at 05:38:00PM +0100, Vitaly Kuznetsov wrote:
>> Paolo Bonzini writes:
>>
>> > On 18/03/21 17:02, Vitaly Kuznetsov wrote:
>> >> KVM doesn't fully support Hyper-V reenlightenment notifications on
>> >&
Paolo Bonzini writes:
> On 19/03/21 10:41, Vitaly Kuznetsov wrote:
>>> What I want to achieve is to forbid migration of VMs with
>>> reenlightenment, if they don't also specify tsc-khz to the frequency of
>>> the TSC on the source host. We can't check it at
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
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/i386/kvm
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
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/kvm/kvm.c
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
es (and
requires from KVM) all currently supported Hyper-V enlightenments except
for 'hv-evmcs' (for now). Unlike 'hv-passthrough' mode, this is going to be
migratable.
Vitaly Kuznetsov (17):
i386: keep hyperv_vendor string up-to-date
i386: invert hyperv_spinlock_attempts setting logic wit
301 - 400 of 523 matches
Mail list logo
