"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 b
"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 reenlightenmen
s works but the migration 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 configurat
works but the migration 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 configu
machine types to preserve 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
props[]' so it was rarely 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/h
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
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
PU models have 'xsaves' enabled from
the very beginning so the comment blaming KVM to explain why Intel CPUs
lack 'xsaves' is likely outdated.
Signed-off-by: Vitaly Kuznetsov
---
The only CPU model where I keep the original comment and don't add
a version supporting 'xsa
Wen Pu writes:
> On 2021/4/7 23:43, Vitaly Kuznetsov wrote:
>> Hyper-V 2016 refuses to boot on Skylake+ CPU models because they lack
>> 'xsaves'/'vmx-xsaves' features and this diverges from real hardware. The
>> same issue emerges with AMD "EPYC"
PU models have 'xsaves' enabled from
the very beginning so the comment blaming KVM to explain why other CPUs
lack 'xsaves' is likely outdated.
Signed-off-by: Vitaly Kuznetsov
---
This patch is a succesor of "[PATCH RFC] target/i386: Add Intel CPU model
versions supporti
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
While this is very unlikely to change, let's avoid hardcoding '12' as
'hyperv_vendor_id' length.
No functional change intended.
Reviewed-by: Eduardo Habkost
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 9 +
1 file changed, 5 insertions(+), 4 d
Return 'false' when hyperv_expand_features() sets an error.
No functional change intended.
Reviewed-by: Eduardo Habkost
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 40 +---
1 file changed, 21 insertions(+), 19 deletions(-)
di
and as we parse Hyper-V features after creating KVM vCPUs and not at
feature expansion time. To support the use-case we first need to make
KVM_GET_SUPPORTED_HV_CPUID ioctl a system-wide ioctl as the existing
vCPU version can't be used that early. This is what KVM part does. With
that done, we can mak
Clarify the fact that 'hv-passthrough' only enables features which are
already known to QEMU and that it overrides all other 'hv-*' settings.
Reviewed-by: Eduardo Habkost
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt | 7 +--
1 file changed, 5 insertions(+),
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).
Reviewed-by: Eduardo Habkost
Signed-off-by: Vitaly Kuznetsov
-
it. Also, 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 c
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.
Reviewed-by: Eduardo Habkost
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 10 +-
1 file changed, 5
blement options (e.g.
'hv-evmcs=2').
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt | 2 +-
target/i386/kvm/kvm.c | 39 +++
2 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/docs/hyperv.txt b/docs/hyperv.txt
index a51953daa
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.
Reviewed-by: Eduardo Habkost
Signed-off-by: Vitaly
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
Eduardo Habkost writes:
> On Tue, Jun 08, 2021 at 02:08:11PM +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
>
Igor Mammedov writes:
> On Mon, 4 Oct 2021 16:04:45 +0200
> Vitaly Kuznetsov wrote:
>
Thanks for the review! As I can see, the patch already made it to
'master':
commit 7f7c8d0ce3630849a4df3d627b11de354fcb3bb0
Author: Vitaly Kuznetsov
Date: Mon Oct 4 16:04:45 2021 +0
Peter Maydell writes:
> On Tue, 13 Jul 2021 at 17:19, Eduardo Habkost wrote:
>>
>> From: Vitaly Kuznetsov
>>
>> 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
>
ERV_CPUID is supported and KVM_CAP_SYS_HYPERV_CPUID
implies KVM_CAP_HYPERV_CPUID so get_supported_hv_cpuid_legacy() is
never really called. Add asserts to strengthen the protection against
broken KVM behavior.
Coverity: CID 1458243
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 14
QEMU coding style requires braces around bodies of ifs.
Reported-by: Peter Maydell
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index e69abe48e3f8..28ca682b1089
Igor Mammedov writes:
> On Thu, 8 Jul 2021 17:02:22 -0400
> Eduardo Habkost wrote:
>
>> On Tue, Jun 08, 2021 at 02:08:17PM +0200, Vitaly Kuznetsov wrote:
>> > For the beginning, just test 'hv-passthrough' and a couple of custom
>> > Hyper-V enlighten
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
---
- Changes since "[PATCH v8
Andrew Jones writes:
> On Fri, Jul 16, 2021 at 02:55:28PM +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 thi
v.txt.
Vitaly Kuznetsov (3):
docs: Briefly describe KVM PV features
i386: Support KVM_CAP_ENFORCE_PV_FEATURE_CPUID
i386: Support KVM_CAP_HYPERV_ENFORCE_CPUID
docs/hyperv.txt | 17 +--
docs/kvm-pv.txt | 103 ++
target/i386/cpu.c
10 and is not
enabled by default in QEMU.
Signed-off-by: Vitaly Kuznetsov
---
docs/kvm-pv.txt | 13 -
target/i386/cpu.c | 2 ++
target/i386/cpu.h | 3 +++
target/i386/kvm/kvm.c | 10 ++
4 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/docs/kvm-pv.t
enlightenments. The feature is supported by Linux >= 5.14 and is
not enabled by default in QEMU.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt | 17 ++---
target/i386/cpu.c | 1 +
target/i386/cpu.h | 1 +
target/i386/kvm/kvm.c | 9 +
4 files changed,
KVM PV features don't seem to be documented anywhere, in particular, the
fact that some of the features are enabled by default and some are not can
only be figured out from the code.
Signed-off-by: Vitaly Kuznetsov
---
docs/kvm-pv.txt | 92 +++
Vitaly Kuznetsov writes:
> This is a continuation of "[PATCH 0/3] i386/kvm: Paravirtualized features
> usage
> enforcement" series, thus v2.
>
> This series implements several unrelated features but as there are code
> dependencies between them I'm sending
Paolo Bonzini writes:
> On 02/09/21 11:35, Vitaly Kuznetsov wrote:
>> This is a continuation of "[PATCH 0/3] i386/kvm: Paravirtualized features
>> usage
>> enforcement" series, thus v2.
>>
>> This series implements several unrelated features but as
KVM PV features don't seem to be documented anywhere, in particular, the
fact that some of the features are enabled by default and some are not can
only be figured out from the code.
Signed-off-by: Vitaly Kuznetsov
---
Changes since "[PATCH v2 0/8] i386: Assorted KVM PV and Hyper
tsc_khz to it. We already
have 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
to proceed 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 +
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/
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
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 acces
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 i
nlightenment'
use-case 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 s
Vitaly Kuznetsov writes:
> The new nested specific enlightenment speeds up L2 vmexits by avoiding
> unnecessary updates to L2 MSR-Bitmap. Support for both VMX and SVM is
> coming to KVM:
> https://lore.kernel.org/kvm/20211129094704.326635-1-vkuzn...@redhat.com/
> https://lore
handling to hv_build_cpuid_leaf() and drop now-unneeded 'hyperv_nested'.
No functional change intended.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.h | 1 -
target/i386/kvm/kvm.c | 23 +++
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/target/
eature on Intel CPUs is coming in v5.17 and is queued for 5.18 for
AMD CPUs.
Vitaly Kuznetsov (3):
i386: Use hv_build_cpuid_leaf() for HV_CPUID_NESTED_FEATURES
i386: Hyper-V Enlightened MSR bitmap feature
i386: Hyper-V XMM fast hypercall input feature
docs/hyperv.txt| 16 +++
The newly introduced enlightenment allow L0 (KVM) and L1 (Hyper-V)
hypervisors to collaborate to avoid unnecessary updates to L2
MSR-Bitmap upon vmexits.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt| 10 ++
target/i386/cpu.c | 2 ++
target/i386/cpu.h
e HV_HYPERCALL_{PARAMS_XMM_AVAILABLE -> XMM_INPUT_AVAILABLE} to
comply with KVM.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt| 6 ++
target/i386/cpu.c | 2 ++
target/i386/cpu.h | 1 +
target/i386/kvm/hyperv-proto.h | 2 +-
target/i386/kvm/
5-level EPT is present in Icelake Server CPUs and is supported by QEMU
('vmx-page-walk-5').
Signed-off-by: Vitaly Kuznetsov
---
scripts/kvm/vmxcap | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/kvm/vmxcap b/scripts/kvm/vmxcap
index 6fe66d5f5753..f140040104bf 100755
---
r-v6'
CPU model with 'vmx-page-walk-5' enabled by default.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 8
1 file changed, 8 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index aa9e6368004c..6e25d1333971 100644
--- a/target/i386/cpu.c
+++ b/ta
Divya Garg writes:
> Hi Vitaly Kuznetsov !
> I was working on hyperv flags and saw that we introduced new
> dependencies some
> time back
> (https://sourcegraph.com/github.com/qemu/qemu/-/commit/c686193072a47032d83cb4e131dc49ae30f9e5d7?visible=1).
> After these changes,
Divya Garg writes:
> On 12/04/22 6:18 pm, Vitaly Kuznetsov wrote:
>> Divya Garg writes:
>>
>>> Hi Vitaly Kuznetsov !
>>> I was working on hyperv flags and saw that we introduced new
>>> dependencies some
>>> time back
&g
The newly introduced enlightenment allow L0 (KVM) and L1 (Hyper-V)
hypervisors to collaborate to avoid unnecessary updates to L2
MSR-Bitmap upon vmexits.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt| 10 ++
target/i386/cpu.c | 2 ++
target/i386/cpu.h
...@redhat.com/
Vitaly Kuznetsov (2):
i386: Use hv_build_cpuid_leaf() for HV_CPUID_NESTED_FEATURES
i386: Hyper-V Enlightened MSR bitmap feature
docs/hyperv.txt| 10 ++
target/i386/cpu.c | 2 ++
target/i386/cpu.h | 2 +-
target/i386/kvm/hyperv-proto.h
handling to hv_build_cpuid_leaf() and drop now-unneeded 'hyperv_nested'.
No functional change intended.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.h | 1 -
target/i386/kvm/kvm.c | 23 +++
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/target/
Vitaly Kuznetsov writes:
> 'XMM fast hypercall input feature' is supported by KVM since v5.14,
> it allows for faster Hyper-V hypercall processing.
>
> 'Enlightened MSR-Bitmap' is a new nested specific enlightenment speeds up
> L2 vmexits by avoiding unnece
instead
as these [are supposed to] come together.
Fixes: 048c95163b4 ("target/i386: work around KVM_GET_MSRS bug for secondary
execution controls")
Suggested-by: Paolo Bonzini
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 41 ++---
1 fil
"Montes, Julio" writes:
> Hi Vitaly
>
> thanks for raising this, unfortunately this patch didn't work for me, I still
> get the same error:
>
>
Does you kernel have 95c5c7c77c ("KVM: nVMX: list VMX MSRs in
KVM_GET_MSR_INDEX_LIST")?
--
Vitaly
"Dr. David Alan Gilbert" writes:
> So you would think that would tkae care of RDSEED exiting - but what
> about VMCS shadowing?
>
SECONDARY_EXEC_SHADOW_VMCS is special, we are able to emulate it in KVM
even when it is not supported by hardware, see
nested_vmx_setup_ctls_msrs():
/*
"Montes, Julio" writes:
>> Does you kernel have 95c5c7c77c ("KVM: nVMX: list VMX MSRs in
>> KVM_GET_MSR_INDEX_LIST")?
>
> I was using linux 5.0.0, now I have 5.3.0 and it's working, thanks for fixing
> this
>
Thanks for the confirmation!
I don't see any good solution for kernels without 95c5c7
If you're seeing "KVM internal error. Suberror: 1" it can be multiple things,
not necessarily the same bug. Could you please confirm that:
- You are running a nested configuration
- The issue is observed with a UEFI booted guest
BTW, kernel 5.4 you have has the patch fixing the original bug.
--
'nested' parameter for kvm_intel module controls whether you're able to
run nested configurations and it is enabled by default, it doesn't say
anything about whether your configuration is nested or not.
Could you please describe your environment? In case it is nested, it will look
like:
L0(host)
With Win10 you need to make sure it is not running Hyper-V under the
hood (e.g. when you enable Hyper-V role Windows will put itself in a VM
-- and thus you will get a nested environment).
To be 100% sure do the following:
# rmmod kvm_intel
# modprobe kvm_intel nested=0
And see if the issue repro
Thanks for checking,
this is a different issue then, please open a new bug. Also, if I
understood you correctly, the problem appeared after an upgrade? It
would make sense to try to bisect between qemu and kernel versions
(personally, I'd start with kernel because it's easier to rollback and
has h
Sorry but I'm not at all familiar with bug reporting process in Ubuntu.
The "KVM internal error. Suberror: 1" issue is definitely not libvirt
related (may be induced by the VM configuration created in libvirt but
that's it).
--
You received this bug notification because you are a member of qemu-
"Dr. David Alan Gilbert" writes:
> * Philippe Mathieu-Daudé (phi...@redhat.com) wrote:
>> Cc'ing David/Paolo in case they have a clue...
>>
>> On 5/14/20 1:27 PM, Li Feng wrote:
>> > Dear all,
>> >
>> > I have encountered a weird crash.
>> > I remember before a few days it works well and I reb
on 6.0 the mistake was
corrected to 'never notify' which sounds logical. Fix QEMU accordingly.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt | 2 +-
target/i386/cpu.c | 2 +-
target/i386/cpu.h | 4 ++--
target/i386/kvm.c | 4 ++--
4 files changed, 6 insertions(+), 6 dele
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
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_
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
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
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
1 - 100 of 524 matches
Mail list logo
