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"
vcpu->arch.hflags == 0".
Paolo, Max, any idea how this is supposed to work?
--
Vitaly
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, E
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"
patches CC here)
Signed-off-by: Vitaly Cheptsov
---
hw/arm/fsl-imx6.c | 8
include/hw/arm/fsl-imx6.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/hw/arm/fsl-imx6.c b/hw/arm/fsl-imx6.c
index 00dafe3f62..4fa7f0b95e 100644
--- a/hw/arm/fsl-imx6.c
+++ b/hw/arm/fsl-imx6.c
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
Alexander,
On Sat, Dec 31, 2022 at 12:34:45PM +0100, Alexander Graf wrote:
> On 31.12.22 11:17, Vitaly Chikunov wrote:
> > On Sat, Dec 31, 2022 at 10:28:21AM +0100, Alexander Graf wrote:
> > > On 30.12.22 19:16, Vitaly Chikunov wrote:
> > > > On Fri, Dec 30, 2022
Alexander,
On Sat, Dec 31, 2022 at 10:28:21AM +0100, Alexander Graf wrote:
> On 30.12.22 19:16, Vitaly Chikunov wrote:
> > On Fri, Dec 30, 2022 at 06:44:14PM +0100, Alexander Graf wrote:
> > >
> > > This is a kvm kernel bug and should be fixed with the latest stable
&
Alexander,
On Fri, Dec 30, 2022 at 06:44:14PM +0100, Alexander Graf wrote:
> Hi Vitaly,
>
> This is a kvm kernel bug and should be fixed with the latest stable releases.
> Which kernel version are you running?
This is on latest v6.0 stable - 6.0.15.
Maybe there could be workaro
Hi,
QEMU 7.2.0 when run on 32-bit x86 architecture fails with:
i586$ qemu-system-i386 -enable-kvm
qemu-system-i386: Could not install MSR_CORE_THREAD_COUNT handler: Success
i586$ qemu-system-x86_64 -enable-kvm
qemu-system-x86_64: Could not install MSR_CORE_THREAD_COUNT handler: Success
M
ll
make CPUID_EXT3_PERFCORE bit disappear when a !enable_pmu VM is migrated
from an old QEMU (pre-patch) to a new one. If so, then additional
precautions should be taking against that (e.g. tying the change to
CPU/machine model versions, for example).
--
Vitaly
solves the problem as well.
--
Vitaly
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
e. Adopt the same approach for the use of the
> ioctl in the Arm-specific KVM code (where we use it to create a
> scratch VM for probing for various things).
>
> For more information, see the mailing list thread:
> https://lore.kernel.org/qemu-devel/8735e0s1zw.wl-...@kernel.org/
>
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
code. Adopt the same approach for the use of the
> ioctl in the Arm-specific KVM code (where we use it to create a
> scratch VM for probing for various things).
>
> For more information, see the mailing list thread:
> https://lore.kernel.org/qemu-devel/8735e0s1zw.wl-...@kernel.or
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.
Marc,
On Fri, Aug 12, 2022 at 04:02:37PM +0100, Marc Zyngier wrote:
> On Fri, 12 Aug 2022 10:25:55 +0100,
> Peter Maydell wrote:
> >
> > I've added some more relevant mailing lists to the cc.
> >
> > On Fri, 12 Aug 2022 at 09:45, Vitaly Chikunov wrote:
>
Sorry, I only noticed today that it's not submitted.
Version is not critical for us, as we build from masters anyway.
Richard, do you know a reason to consider this critical?
On Wed, 10 Aug 2022 at 13:04, Peter Maydell
wrote:
> On Wed, 10 Aug 2022 at 21:00, Vitaly Buka wrote:
> &g
How can we land this one?
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
aarch64 stores MTE tags in target_date, and they should be reset by
MADV_DONTNEED.
Signed-off-by: Vitaly Buka
---
accel/tcg/translate-all.c | 24
include/exec/cpu-all.h| 1 +
linux-user/mmap.c | 2 ++
3 files changed, 27 insertions(+)
diff --git a/accel
ying this patch one will be able to communicate
with QEMU when using "-nic socket,mcast=230.0.0.1:1234,model=virtio-net-pci"
from QEMU or macOS itself.
Cc: Jason Wang
Cc: Daniel P. Berrange
Cc: Philippe Mathieu-Daudé
Signed-off-by: Vitaly Cheptsov
---
net/socket.c | 18 +++
lly after applying this patch one will be able to communicate with QEMU
when using "-nic socket,mcast=230.0.0.1:1234,model=virtio-net-pci" from QEMU or
macOS itself.
Best regards,
Vitaly
> On 31 May 2022, at 10:02, Jason Wang wrote:
>
> On Wed, May 18, 2022 at 3:
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
V2 version of the previous patch ensures to keep compatibility with non-Apple
platforms to avoid any potential compatibility issues with e.g. Windows
mentioned in the review.
> On 18 May 2022, at 10:39, Vitaly Cheptsov wrote:
>
> Cc: Jason Wang
> Cc: Daniel P. Berrange
&g
Cc: Jason Wang
Cc: Daniel P. Berrange
Cc: Philippe Mathieu-Daudé
Signed-off-by: Vitaly Cheptsov
---
net/socket.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/net/socket.c b/net/socket.c
index bfd8596250..583f788a22 100644
--- a/net/socket.c
+++ b/net/socket.c
Gentle ping :)
> On 3 May 2022, at 19:10, Vitaly Cheptsov wrote:
>
> Hi Daniel,
>
> Thank you for your comment. Socket implementation on all the systems is
> rather complicated, and while I am fine to update the patch with better
> reasoning, it needs to work on macOS
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
any address, even one not bound to
> any available network interface in the system.
This makes some sense, because if I change a.py and b.py
- to bind to MCAST_GRP instead of “0.0.0.0”
- to not set SO_REUSEPORT
I get "Can't assign requested address” error at sendto in b.py. Same thin
Cc: Philippe Mathieu-Daudé
Signed-off-by: Vitaly Cheptsov
---
net/socket.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index ea5220a2eb..8b2c6c4bb8 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -252,10 +252,24 @@ static
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/
On Thu, Feb 17, 2022 at 10:26:37AM +0100, Christian Schoenebeck wrote:
> On Mittwoch, 16. Februar 2022 19:18:21 CET Vitaly Chikunov wrote:
> > `struct dirent' returned from readdir(3) could be shorter (or longer)
> > than `sizeof(struct dirent)', thus memcpy of sizeof leng
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/841
Cc: qemu-sta...@nongnu.org
Co-authored-by: Christian Schoenebeck
Reviewed-by: Dmitry V. Levin
Signed-off-by: Vitaly Chikunov
---
Tested on x68-64 Linux with btrfs-progs tests and qos-test -m slow.
Changes since v4:
- Zero clear V9fsSynthOpenStat
1 - 100 of 614 matches
Mail list logo
