Vitaly Kuznetsov writes:
> Changes since v3:
> - Split the change into two patches [Philippe Mathieu-Daude].
>
> It was found that 'qemu-nbd' is not able to work with some disk images
> exported from Azure as it uses a currently unknown 'wa\0\0' 'creator a
hods for determining the image
size: CHS and 'current_size' and the list of known 'creator app's is used
to decide between the two. Invert the logic in QEMU and make 'current_size'
the default as it seems that VPC and old QEMU are the only two legacy apps
where preferr
oid adding every new creator app to
the list.
Signed-off-by: Vitaly Kuznetsov
---
block/vpc.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/block/vpc.c b/block/vpc.c
index fb0ded1c4344..a5f626baf04a 100644
--- a/block/vpc.c
+++ b/block/vpc.c
@@ -237,6 +237,7 @@ s
In preparation to making changes to the logic deciding whether CHS or
'current_size' need to be used in determining the image size, split off
vpc_ignore_current_size() helper.
No functional change intended.
Signed-off-by: Vitaly Kuznetsov
---
block/
oid adding every new creator app to
the list.
Signed-off-by: Vitaly Kuznetsov
---
Changes since v1/v2: invert the logic and make 'vpc' and 'qemu' use CHS
while defaulting to current_size.
---
block/vpc.c | 65 -
1 file ch
Eric Blake writes:
> On Mon, Nov 18, 2024 at 03:36:46PM +0100, Vitaly Kuznetsov wrote:
>> It was found that 'qemu-nbd' is not able to work with some disk images
>> exported from Azure. Looking at the 512b footer (which contains VPC
>> metadata):
>>
>>
d to determine how it can get image size. Apparently, Azure uses 'new'
method, just like Hyper-V.
Signed-off-by: Vitaly Kuznetsov
---
Alternatively, we can probably make 'current_size' the default and only use
CHS for 'vpc '/'qemu'.
---
block/vpc.c | 2 ++
1 file cha
Vitaly Kuznetsov writes:
> It was found that 'qemu-nbd' is not able to work with some disk images
> exported from Azure. Looking at the 512b footer (which contains VPC
> metadata):
>
> 63 6f 6e 65 63 74 69 78 00 00 00 02 00 01 00 00 |conectix|
> 00
d to determine how it can get image size. Apparently, Azure uses 'new'
method, just like Hyper-V.
Signed-off-by: Vitaly Kuznetsov
---
Alternatively, we can probably make 'current_size' the default and only use
CHS for 'vpc '/'qemu'.
---
block/vpc.c | 2 ++
1 file cha
el Tokarev
Fixes: bbf3810f2c4f ("target/i386: Fix conditional CONFIG_SYNDBG enablement")
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 8e17942c3ba1..11f9526c8f8c 100644
Michael Tokarev writes:
> 17.09.2024 19:00, Vitaly Kuznetsov пишет:
>> Putting HYPERV_FEAT_SYNDBG entry under "#ifdef CONFIG_SYNDBG" in
>> 'kvm_hyperv_properties' array is wrong: as HYPERV_FEAT_SYNDBG is not
>> the highest feature number, the result i
Vitaly Kuznetsov writes:
> Vitaly Kuznetsov writes:
>
>> Changes since '[PATCH RESEND v3 0/3] i386: Fix Hyper-V Gen1 guests stuck
>> on boot with 'hv-passthrough':
>>
>> - Added "target/i386: Make sure SynIC state is really updated before
&g
Vitaly Kuznetsov writes:
> Changes since '[PATCH RESEND v3 0/3] i386: Fix Hyper-V Gen1 guests stuck
> on boot with 'hv-passthrough':
>
> - Added "target/i386: Make sure SynIC state is really updated before KVM_RUN"
> to the set.
>
> This is
e it as
one-off to skip 'hv-syndbg' when enabling features in 'hv-passthrough'
mode. Note, "-cpu host,hv-passthrough,hv-syndbg" can still be used if
needed.
As both 'hv-passthrough' and 'hv-syndbg' are debug features, the change
should not
issues, mostly detected by tests. On top of that, the patchset updates
Hyper-V related documentation adding recommendations.
Vitaly Kuznetsov (4):
target/i386: Fix conditional CONFIG_SYNDBG enablement
target/i386: Exclude 'hv-syndbg' from 'hv-passthrough'
target/i386: M
s SynIC state
does not get updated so often (and async_safe_run_on_cpu() is a big hammer
anyways).
Reported-by: Jan Richter
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/hyperv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/i386/kvm/hyperv.c b/target/i386/kvm/hyperv.c
ONFIG_SYNDBG builds.
Leave an 'assert' sentinel in hyperv_feature_supported() making sure there
are no 'holes' or improperly defined features in 'kvm_hyperv_properties'.
Fixes: d8701185f40c ("hw: hyperv: Initial commit for Synthetic Debugging
device"
While hyperv.rst already has all currently implemented Hyper-V
enlightenments documented, it may be unclear what is the recommended set to
achieve the best result. Add the corresponding section to the doc.
Signed-off-by: Vitaly Kuznetsov
---
docs/system/i386/hyperv.rst | 30
s SynIC state
does not get updated so often (and async_safe_run_on_cpu() is a big hammer
anyways).
Reported-by: Jan Richter
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/hyperv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/i386/kvm/hyperv.c b/target/i386/kvm/hyperv.c
Vitaly Kuznetsov writes:
> Changes since 'RESEND v2':
> - Included 'docs/system: Add recommendations to Hyper-V enlightenments doc'
> in the set as it also requires a "RESEND")
Ping)
>
> Hyper-V Gen1 guests are getting stuck on boot when 'hv
Zhao Liu writes:
> Hi Vitaly,
>
> On Tue, Mar 05, 2024 at 05:42:04PM +0100, Vitaly Kuznetsov wrote:
>> Date: Tue, 5 Mar 2024 17:42:04 +0100
>> From: Vitaly Kuznetsov
>> Subject: [PATCH RESEND v3 3/3] docs/system: Add recommendations to Hyper-V
>> enlighten
e it as
one-off to skip 'hv-syndbg' when enabling features in 'hv-passthrough'
mode. Note, "-cpu host,hv-passthrough,hv-syndbg" can still be used if
needed.
As both 'hv-passthrough' and 'hv-syndbg' are debug features, the change
should not
!CONFIG_SYNDBG.
Fix both issues; exclude 'hv-syndbg' from 'hv-passthrough' and don't allow
to turn on 'hv-syndbg' for !CONFIG_SYNDBG builds.
Vitaly Kuznetsov (3):
i386: Fix conditional CONFIG_SYNDBG enablement
i386: Exclude 'hv-syndbg&#x
While hyperv.rst already has all currently implemented Hyper-V
enlightenments documented, it may be unclear what is the recommended set to
achieve the best result. Add the corresponding section to the doc.
Signed-off-by: Vitaly Kuznetsov
---
docs/system/i386/hyperv.rst | 30
ONFIG_SYNDBG builds.
Leave an 'assert' sentinel in hyperv_feature_supported() making sure there
are no 'holes' or improperly defined features in 'kvm_hyperv_properties'.
Fixes: d8701185f40c ("hw: hyperv: Initial commit for Synthetic Debugging
device"
Eiichi Tsukata wrote:
>>
>> Hi all, appreciate any comments or feedbacks on the patch.
>>
>> Thanks,
>> Eiichi
>>
>>> On Nov 1, 2023, at 23:04, Vitaly Kuznetsov wrote:
>>>
>>> Eiichi Tsukata writes:
>>>
>>
While hyperv.rst already has all currently implemented Hyper-V
enlightenments documented, it may be unclear what is the recommended set to
achieve the best result. Add the corresponding section to the doc.
Signed-off-by: Vitaly Kuznetsov
---
docs/system/i386/hyperv.rst | 30
e it as
one-off to skip 'hv-syndbg' when enabling features in 'hv-passthrough'
mode. Note, "-cpu host,hv-passthrough,hv-syndbg" can still be used if
needed.
As both 'hv-passthrough' and 'hv-syndbg' are debug features, the change
should not
nected issues:
- 'hv-passthrough' enables 'hv-syndbg' and this is undesired.
- 'hv-syndbg's support by KVM is detected incorrectly when !CONFIG_SYNDBG.
Fix both issues; exclude 'hv-syndbg' from 'hv-passthrough' and don't allow
to turn on
ONFIG_SYNDBG builds.
Leave an 'assert' sentinel in hyperv_feature_supported() making sure there
are no 'holes' or improperly defined features in 'kvm_hyperv_properties'.
Fixes: d8701185f40c ("hw: hyperv: Initial commit for Synthetic Debugging
device"
Eiichi Tsukata writes:
> FYI: The EINVAL in vmx_set_nested_state() is caused by the following
> condition:
> * vcpu->arch.hflags == 0
> * kvm_state->hdr.vmx.smm.flags == KVM_STATE_NESTED_SMM_VMXON
This is a weird state indeed,
'vcpu->arch.hflags == 0' means we're not in SMM and not in guest mo
Cc'ing Max :-) At first glance the condition in vmx_set_nested_state()
is correct so I guess we either have a stale
KVM_STATE_NESTED_RUN_PENDING when in SMM or stale smm.flags when outside
of it...
Philippe Mathieu-Daudé writes:
> Cc'ing Vitaly.
>
> On 26/10/23 07:49, Eiichi Tsukata wrote:
>> Hi
ONFIG_SYNDBG builds.
Leave an 'assert' sentinel in hyperv_feature_supported() making sure there
are no 'holes' or improperly defined features in 'kvm_hyperv_properties'.
Fixes: d8701185f40c ("hw: hyperv: Initial commit for Synthetic Debugging
device"
; enables 'hv-syndbg' and this is undesired.
- 'hv-syndbg's support by KVM is detected incorrectly when !CONFIG_SYNDBG.
Fix both issues; exclude 'hv-syndbg' from 'hv-passthrough' and don't allow
to turn on 'hv-syndbg' for !CONFIG_SYNDBG bu
e it as
one-off to skip 'hv-syndbg' when enabling features in 'hv-passthrough'
mode. Note, "-cpu host,hv-passthrough,hv-syndbg" can still be used if
needed.
As both 'hv-passthrough' and 'hv-syndbg' are debug features, the change
should not
Vitaly Kuznetsov writes:
> Vitaly Kuznetsov writes:
>
>> Vitaly Kuznetsov writes:
>>
>>> Hyper-V Gen1 guests are getting stuck on boot when 'hv-passthrough' is
>>> used. While 'hv-passthrough' is a debug only feature, this significantly
&
Vitaly Kuznetsov writes:
> Vitaly Kuznetsov writes:
>
>> Hyper-V Gen1 guests are getting stuck on boot when 'hv-passthrough' is
>> used. While 'hv-passthrough' is a debug only feature, this significantly
>> limit its usefullness. While debuggin
Vitaly Kuznetsov writes:
> Hyper-V Gen1 guests are getting stuck on boot when 'hv-passthrough' is
> used. While 'hv-passthrough' is a debug only feature, this significantly
> limit its usefullness. While debugging the problem, I found that there are
> two l
e it as
one-off to skip 'hv-syndbg' when enabling features in 'hv-passthrough'
mode. Note, "-cpu host,hv-passthrough,hv-syndbg" can still be used if
needed.
As both 'hv-passthrough' and 'hv-syndbg' are debug features, the change
should not
; enables 'hv-syndbg' and this is undesired.
- 'hv-syndbg's support by KVM is detected incorrectly when !CONFIG_SYNDBG.
Fix both issues; exclude 'hv-syndbg' from 'hv-passthrough' and don't allow
to turn on 'hv-syndbg' for !CONFIG_SYNDBG bu
ONFIG_SYNDBG builds.
Leave an 'assert' sentinel in hyperv_feature_supported() making sure there
are no 'holes' or improperly defined features in 'kvm_hyperv_properties'.
Fixes: d8701185f40c ("hw: hyperv: Initial commit for Synthetic Debugging
device"
or KVM_GET_SUPPORTED_HV_CPUID
>> ioctl) for HyperV
>> features.
>> Apologies in advance if i misunderstood something.
>>
Thanks for Ccing me.
Hyper-V features should appear in QMP since
commit 071ce4b03becf9e2df6b758fde9609be8ddf56f1
Author: Vitaly Kuznetsov
Liang Yan writes:
> With cpu.pmu=off, perfctr_core could still be seen in an AMD guest cpuid.
> By further digging, I found cpu.perfctr_core did the trick. However,
> considering the 'enable_pmu' in KVM could work on both Intel and AMD,
> we may add AMD PMU control under 'enabe_pmu' in QEMU too.
Paolo Bonzini writes:
> Hi, a similar patch is now in.
>
Indeed,
commit c4ef867f2949bf2a2ae18a4e27cf1a34bbc8aecb
Author: Ray Zhang
Date: Thu Sep 22 18:05:23 2022 +0800
target/i386/kvm: fix kvmclock_current_nsec: Assertion `time.tsc_timestamp
<= migration_tsc' failed
solves the pro
Vitaly Kuznetsov writes:
> Vitaly Kuznetsov writes:
>
>> KVM commit c68dc1b577ea ("KVM: x86: Report host tsc and realtime values in
>> KVM_GET_CLOCK") broke migration of certain workloads, e.g. Win11 + WSL2
>> guest reboots immediately after migration. KVM, how
Vitaly Kuznetsov writes:
> KVM commit c68dc1b577ea ("KVM: x86: Report host tsc and realtime values in
> KVM_GET_CLOCK") broke migration of certain workloads, e.g. Win11 + WSL2
> guest reboots immediately after migration. KVM, however, is not to
> blame this time. Whe
ult is all supported flags (which the above mentioned KVM commit
enhanced) but kvm_has_adjust_clock_stable() wants it to be
KVM_CLOCK_TSC_STABLE precisely. The result is that 'clock_is_reliable'
is not set in vmstate and the saved clock reading is discarded in
kvmclock_vm_state_change().
S
Make sure env->nested_state is cleaned up when a vCPU is reset, it may
be stale after an incoming migration, kvm_arch_put_registers() may
end up failing or putting vCPU in a weird state.
Reviewed-by: Maxim Levitsky
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c |
URE_CONTROL before
kvm_put_sregs2() (and kvm_put_nested_state()), this ensures vCPU gets
kicked out of VMX root operation.
Vitaly Kuznetsov (2):
i386: reset KVM nested state upon CPU reset
i386: do kvm_put_msr_feature_control() first thing when vCPU is reset
target/i386/kvm/kvm.c | 54
sted_state() and not after it, especially when 'real' nested
state is set.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 4f8dacc1d4b5.
Maxim Levitsky writes:
> On Wed, 2022-08-10 at 16:00 +0200, Vitaly Kuznetsov wrote:
>> Setting nested state upon migration needs to happen after kvm_put_sregs2()
>> to e.g. have EFER.SVME set. This, however, doesn't work for vCPU reset:
>> when vCPU is in VMX root oper
Make sure env->nested_state is cleaned up when a vCPU is reset, it may
be stale after an incoming migration, kvm_arch_put_registers() may
end up failing or putting vCPU in a weird state.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 37 +++--
1 f
reset (kvm_arch_reset_vcpu() -> kvm_init_nested_state()), calling
kvm_put_nested_state() before kvm_put_sregs2() is OK, this will ensure
that vCPU is *not* in VMX root opertaion.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 20 ++--
1 file changed, 18 insertio
part: the immediate issue could've probably been solved in KVM too
by avoiding vmx_is_valid_cr4() check from __set_sregs2() and hoping that
someone will check for the resulting inconsistency later. I don't quite
like this option so I didn't explore it in depth.
Vitaly Kuznetsov (2
rSTify docs/hyperv.txt and link it from docs/system/target-i386.rst.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt | 303
docs/system/i386/hyperv.rst | 288 ++
docs/system/target-i386.rst | 1 +
3 files
Hyper-V TLFS allows for L0 and L1 hypervisors to collaborate on L2's
TLB flush hypercalls handling. With the correct setup, L2's TLB flush
hypercalls can be handled by L0 directly, without the need to exit to
L1.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt
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/
directly handle
L2's TLB flush hypercalls without the need to exit to L1 (Hyper-V).
The last two features are not merged in KVM yet:
https://lore.kernel.org/kvm/20220525090133.1264239-1-vkuzn...@redhat.com/
however, there's no direct dependency on the kernel part as thanks to
KVM_GET_SU
e bit
wasn't exposed then. Now, as KVM gains support for fine-grained TLB
flush handling, exposing this feature starts making sense.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt| 7 +++
target/i386/cpu.c | 2 ++
target/i386/cpu.h | 1
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 | 25 +++--
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/t
Vitaly Kuznetsov writes:
> Paolo Bonzini writes:
>
>>> This series enables four new KVM Hyper-V enlightenmtes [...]
>>>
>>> docs/hyperv.txt| 34 ++
>>
>> Queued, thanks.
>
> Thanks!
>
It seems these pa
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| 9 +
target/i386/cpu.c | 2 ++
target/i386/cpu.h
ation'
> +},
> +cap_msr = MSR_IA32_VMX_PROCBASED_CTLS3,
> +),
> +
> Control(
> name = 'VM-Exit controls',
> bits = {
Not sure which particular CPUs are going to implement this (whould be
nice to add this info to the blurb) but this matches Intel doc
(https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html)
and "IPI virtualization support for VM" series for KVM, so
Reviewed-by: Vitaly Kuznetsov
--
Vitaly
rSTify docs/hyperv.txt and link it from docs/system/target-i386.rst.
Signed-off-by: Vitaly Kuznetsov
---
- The patch is supposed to be applied on top of "[PATCH v3 0/5] i386:
Enable newly introduced KVM Hyper-V enlightenments".
---
docs/hyperv.txt
Paolo Bonzini writes:
>> This series enables four new KVM Hyper-V enlightenmtes [...]
>>
>> docs/hyperv.txt| 34 ++
>
> Queued, thanks.
Thanks!
> Would you please convert hyperv.txt to rST in docs/system/i386?
Sure, it's on my TODO list.
--
Vitaly
e bit
wasn't exposed then. Now, as KVM gains support for fine-grained TLB
flush handling, exposing this feature starts making sense.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt| 7 +++
target/i386/cpu.c | 2 ++
target/i386/cpu.h | 1
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
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/
as thanks to
KVM_GET_SUPPORTED_HV_CPUID no new capabilities are introduced.
Vitaly Kuznetsov (5):
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
i386: Hyper-V Support extended GVA ranges
Hyper-V TLFS allows for L0 and L1 hypervisors to collaborate on L2's
TLB flush hypercalls handling. With the correct setup, L2's TLB flush
hypercalls can be handled by L0 directly, without the need to exit to
L1.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt
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/
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
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,
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
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
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
---
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/
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
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 +++
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:
> 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/
...@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
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
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
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
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
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
nt to give.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm/kvm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index bd0b53416315..430007c2691a 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -82
ATCH8 changes the default Hyper-V version to 2016
Vitaly Kuznetsov (8):
i386: Add 6.2 machine types
i386: docs: Briefly describe KVM PV features
i386: Support KVM_CAP_ENFORCE_PV_FEATURE_CPUID
i386: Support KVM_CAP_HYPERV_ENFORCE_CPUID
i386: Move HV_APIC_ACCESS_RECOMMENDED bit setting
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
r 7.2 machine types only.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt | 2 +-
hw/i386/pc.c | 6 +-
target/i386/cpu.c | 6 +++---
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/docs/hyperv.txt b/docs/hyperv.txt
index 7803495468b7..5d99fd9a72b8 100644
--- a/docs/hyper
Introduce 6.2 machine types and the required infrastructure for adding
compat properties to pre-6.2 machine types.
Signed-off-by: Vitaly Kuznetsov
---
hw/core/machine.c| 3 +++
hw/i386/pc.c | 3 +++
hw/i386/pc_piix.c| 14 +-
hw/i386/pc_q35.c | 13
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,
-16: Major Version
Bits 15-0: Minor Version
ECX Service Pack
EDX Bits 31-24: Service Branch
Bits 23-0: Service Number
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt | 14 ++
target/i386/cpu.c | 15 +++
target/i386/cpu.h | 7 ++-
target/i386
guest tries to use AutoEOI feature with SynIC. With
'HV_DEPRECATING_AEOI_RECOMMENDED' bit exposed, modern enough Windows/
Hyper-V versions should follow the recommendation and not use the
(unwanted) feature.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt| 10
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 +++
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 +++
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,
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
1 - 100 of 542 matches
Mail list logo
