From: Yang Zhang
If not config smp, posted interrupt logic will not work. So we should not
send posted interrupt and let vcpu to pick the pending interrupt before
vmentry.
Without this patch, the build fails when CONFIG_SMP is disabled.
Thanks Randy to report this issue.
Reported-by: Randy
On 2017/8/16 12:04, Michael S. Tsirkin wrote:
On Thu, Jun 22, 2017 at 11:22:13AM +, root wrote:
From: Yang Zhang
This patch introduce a new mechanism to poll for a while before
entering idle state.
David has a topic in KVM forum to describe the problem on current KVM VM
when running some
On 2017/8/17 0:56, Radim Krčmář wrote:
2017-08-16 17:10+0300, Michael S. Tsirkin:
On Wed, Aug 16, 2017 at 03:34:54PM +0200, Paolo Bonzini wrote:
Microsoft pointed out privately to me that KVM's handling of
KVM_FAST_MMIO_BUS is invalid. Using skip_emulation_instruction is invalid
in EPT misconf
On 2017/8/17 16:31, Wanpeng Li wrote:
2017-08-17 16:28 GMT+08:00 Wanpeng Li :
2017-08-17 16:07 GMT+08:00 Yang Zhang :
On 2017/8/17 0:56, Radim Krčmář wrote:
2017-08-16 17:10+0300, Michael S. Tsirkin:
On Wed, Aug 16, 2017 at 03:34:54PM +0200, Paolo Bonzini wrote:
Microsoft pointed out
On 2017/8/17 16:51, Wanpeng Li wrote:
2017-08-17 16:48 GMT+08:00 Yang Zhang :
On 2017/8/17 16:31, Wanpeng Li wrote:
2017-08-17 16:28 GMT+08:00 Wanpeng Li :
2017-08-17 16:07 GMT+08:00 Yang Zhang :
On 2017/8/17 0:56, Radim Krčmář wrote:
2017-08-16 17:10+0300, Michael S. Tsirkin:
On
On 2017/6/22 19:22, root wrote:
From: Yang Zhang
Sorry to use wrong username to send patch because i am using a new
machine which don't setup the git config well.
Some latency-intensive workload will see obviously performance
drop when running inside VM. The main reason is tha
> On 6 Nov 2017, at 06:58, Andreas Färber wrote:
>
>> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
>>> On 4 November 2017 at 20:06, Andreas Färber wrote:
Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
> On 4 November 2017 at 15:30, Andreas Färber wrote:
>> Am 04.11.2017 um 22:5
On 2016/5/21 2:37, David Matlack wrote:
On Thu, May 19, 2016 at 7:04 PM, Yang Zhang wrote:
On 2016/5/20 2:36, David Matlack wrote:
On Thu, May 19, 2016 at 11:01 AM, David Matlack
wrote:
On Thu, May 19, 2016 at 6:27 AM, Wanpeng Li wrote:
From: Wanpeng Li
If an emulated lapic timer
On 2016/5/24 2:04, David Matlack wrote:
On Sun, May 22, 2016 at 6:26 PM, Yang Zhang wrote:
On 2016/5/21 2:37, David Matlack wrote:
It's not obvious to me why polling for a timer interrupt would improve
context switch latency. Can you explain a bit more?
We have a workload which using
On 2016/5/24 9:16, David Matlack wrote:
On Mon, May 23, 2016 at 6:13 PM, Yang Zhang wrote:
On 2016/5/24 2:04, David Matlack wrote:
On Sun, May 22, 2016 at 6:26 PM, Yang Zhang
wrote:
On 2016/5/21 2:37, David Matlack wrote:
It's not obvious to me why polling for a timer interrupt
On 2016/5/25 7:37, David Matlack wrote:
On Tue, May 24, 2016 at 4:11 PM, Wanpeng Li wrote:
2016-05-25 6:38 GMT+08:00 David Matlack :
On Tue, May 24, 2016 at 12:57 AM, Wanpeng Li wrote:
From: Wanpeng Li
If an emulated lapic timer will fire soon(in the scope of 10us the
base of dynamic halt-
On 2016/5/20 2:36, David Matlack wrote:
On Thu, May 19, 2016 at 11:01 AM, David Matlack wrote:
On Thu, May 19, 2016 at 6:27 AM, Wanpeng Li wrote:
From: Wanpeng Li
If an emulated lapic timer will fire soon(in the scope of 10us the
base of dynamic halt-polling, lower-end of message passing wo
On 2015/12/3 23:11, Paolo Bonzini wrote:
In theory this should have broken EPT on 32-bit kernels (due to
reading the high part of natural-width field GUEST_CR3). Not sure
if no one noticed or the processor behaves differently from the
documentation.
It seems we will check the success of vmcs_w
On 2015/12/14 5:28, Alexander Duyck wrote:
This patch set is meant to be the guest side code for a proof of concept
involving leaving pass-through devices in the guest during the warm-up
phase of guest live migration. In order to accomplish this I have added a
new function called dma_mark_dirty
On 2015/12/14 12:54, Alexander Duyck wrote:
On Sun, Dec 13, 2015 at 6:27 PM, Yang Zhang wrote:
On 2015/12/14 5:28, Alexander Duyck wrote:
This patch set is meant to be the guest side code for a proof of concept
involving leaving pass-through devices in the guest during the warm-up
phase of
On 2015/12/14 13:46, Alexander Duyck wrote:
On Sun, Dec 13, 2015 at 9:22 PM, Yang Zhang wrote:
On 2015/12/14 12:54, Alexander Duyck wrote:
On Sun, Dec 13, 2015 at 6:27 PM, Yang Zhang
wrote:
On 2015/12/14 5:28, Alexander Duyck wrote:
This patch set is meant to be the guest side code for
On 2016/1/20 22:35, Michael S. Tsirkin wrote:
On Tue, Dec 01, 2015 at 02:39:45PM +0800, Jason Wang wrote:
This patch tries to poll for new added tx buffer or socket receive
queue for a while at the end of tx/rx processing. The maximum time
spent on polling were specified through a new kind of vr
On 2016/1/20 9:42, Feng Wu wrote:
When the interrupt is not single destination any more, we need
to change back IRTE to remapped mode explicitly.
Signed-off-by: Feng Wu
---
arch/x86/kvm/vmx.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx.c b
On 2016/1/21 11:14, Wu, Feng wrote:
-Original Message-
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
Sent: Thursday, January 21, 2016 11:06 AM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: linux-kernel@vger.kernel.org; k...@vger.kernel.org
Subject: Re: [PATCH v3 1/4
On 2016/1/21 12:42, Wu, Feng wrote:
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Yang Zhang
Sent: Thursday, January 21, 2016 11:35 AM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: linux-kernel@vger.kernel.org; k
On 2016/1/20 9:42, Feng Wu wrote:
Use vector-hashing to deliver lowest-priority interrupts, As an
example, modern Intel CPUs in server platform use this method to
handle lowest-priority interrupts.
Signed-off-by: Feng Wu
---
v3:
- Fix a bug for sparse topologies, in that case, vcpu_id is not eq
On 2016/1/21 13:07, Wu, Feng wrote:
-Original Message-
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
Sent: Thursday, January 21, 2016 1:00 PM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: linux-kernel@vger.kernel.org; k...@vger.kernel.org
Subject: Re: [PATCH v3 1/4
On 2016/1/21 13:33, Wu, Feng wrote:
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Yang Zhang
Sent: Thursday, January 21, 2016 1:24 PM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: linux-kernel
On 2016/1/21 13:41, Wu, Feng wrote:
-Original Message-
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
Sent: Thursday, January 21, 2016 1:36 PM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: linux-kernel@vger.kernel.org; k...@vger.kernel.org
Subject: Re: [PATCH v3 1/4
On 2016/1/21 13:46, Wu, Feng wrote:
-Original Message-
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
Sent: Thursday, January 21, 2016 1:43 PM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: linux-kernel@vger.kernel.org; k...@vger.kernel.org
Subject: Re: [PATCH v3 2/4
On 2016/1/21 14:02, Wu, Feng wrote:
-Original Message-
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
Sent: Thursday, January 21, 2016 1:58 PM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: linux-kernel@vger.kernel.org; k...@vger.kernel.org
Subject: Re: [PATCH v3 2/4
On 2016/1/21 13:13, Michael S. Tsirkin wrote:
On Thu, Jan 21, 2016 at 10:11:35AM +0800, Yang Zhang wrote:
On 2016/1/20 22:35, Michael S. Tsirkin wrote:
On Tue, Dec 01, 2015 at 02:39:45PM +0800, Jason Wang wrote:
This patch tries to poll for new added tx buffer or socket receive
queue for a
On 2016/1/22 0:35, rkrc...@redhat.com wrote:
2016-01-21 13:44+0800, Yang Zhang:
On 2016/1/21 13:41, Wu, Feng wrote:
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
We may have different understanding on PI mode. My understanding is if
we set the IRTE to PI format, than the subsequent
On 2016/1/22 1:21, rkrc...@redhat.com wrote:
2016-01-21 05:33+, Wu, Feng:
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Yang Zhang
On 2016/1/20 9:42, Feng Wu wrote:
+ /*
+* We may find a
On 2015/12/31 15:13, Jason Wang wrote:
This patch tries to implement an device IOTLB for vhost. This could be
used with for co-operation with userspace(qemu) implementation of
iommu for a secure DMA environment in guest.
The idea is simple. When vhost meets an IOTLB miss, it will request
the ass
On 2016/1/4 14:22, Jason Wang wrote:
On 01/04/2016 09:39 AM, Yang Zhang wrote:
On 2015/12/31 15:13, Jason Wang wrote:
This patch tries to implement an device IOTLB for vhost. This could be
used with for co-operation with userspace(qemu) implementation of
iommu for a secure DMA environment in
On 2016/4/5 5:00, Rik van Riel wrote:
On Mon, 2016-04-04 at 16:46 -0400, Luiz Capitulino wrote:
When a vCPU runs on a nohz_full core, the hrtimer used by
the lapic emulation code can be migrated to another core.
When this happens, it's possible to observe milisecond
latency when delivering timer
On 2016/4/5 23:54, Radim Krčmář wrote:
2016-04-05 14:18+0800, Yang Zhang:
On 2016/4/5 5:00, Rik van Riel wrote:
Given that delivering a timer to a guest seems to
involve trapping from the guest to the host, anyway,
I don't see a downside to your patch.
If that is ever changed (eg. all
On 2016/3/24 21:07, Paolo Bonzini wrote:
On 24/03/2016 14:06, Yang Zhang wrote:
I mean why not keep the old way that only activate the eager_fpu while
guest sees the MPX bit in CPUID, like:
vcpu->arch.eager_fpu = use_eager_fpu() && guest_cpuid_has_mpx(vcpu);
If the host uses ea
On 2016/7/13 3:20, Paolo Bonzini wrote:
UMIP (User-Mode Instruction Prevention) is a feature of future
Intel processors (Cannonlake?) that blocks SLDT, SGDT, STR, SIDT
I remember there is no Cannonlake any more. It should be Icelake. :)
and SMSW from user-mode processes.
Do you know the bac
On 2016/7/13 3:20, Paolo Bonzini wrote:
UMIP (User-Mode Instruction Prevention) is a feature of future
Intel processors (Cannonlake?) that blocks SLDT, SGDT, STR, SIDT
and SMSW from user-mode processes.
On Intel systems it's *almost* possible to emulate it; it slows
down the instructions when th
On 2016/7/13 17:35, Paolo Bonzini wrote:
On 13/07/2016 11:21, Yang Zhang wrote:
+if ((cr4 & X86_CR4_UMIP) && !boot_cpu_has(X86_FEATURE_UMIP)) {
+vmcs_set_bits(SECONDARY_VM_EXEC_CONTROL,
+ SECONDARY_EXEC_DESC);
+hw_cr4 &= ~X86_CR4_U
On 2016/7/13 17:35, Paolo Bonzini wrote:
On 13/07/2016 11:21, Yang Zhang wrote:
+static int handle_desc(struct kvm_vcpu *vcpu)
+{
+WARN_ON(!(vcpu->arch.cr4 & X86_CR4_UMIP));
I think WARN_ON is too heavy since a malicious guest may trigger it always.
I missed this---how so?
On 2016/8/9 2:16, Radim Krčmář wrote:
msr bitmap can be used to avoid a VM exit (interception) on guest MSR
accesses. In some configurations of VMX controls, the guest can even
directly access host's x2APIC MSRs. See SDM 29.5 VIRTUALIZING MSR-BASED
APIC ACCESSES.
L2 could read all L0's x2APIC
On 2016/8/9 20:23, Radim Krčmář wrote:
2016-08-09 17:32+0800, Yang Zhang:
On 2016/8/9 2:16, Radim Krčmář wrote:
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
@@ -6995,16 +6982,21 @@ static int handle_vmon(struct kvm_vcpu *vcpu)
return 1;
}
+ if
On 2016/8/9 18:19, Wincy Van wrote:
On Tue, Aug 9, 2016 at 5:32 PM, Yang Zhang wrote:
On 2016/8/9 2:16, Radim Krčmář wrote:
msr bitmap can be used to avoid a VM exit (interception) on guest MSR
accesses. In some configurations of VMX controls, the guest can even
directly access host&#
On 2016/7/8 1:15, Radim Krčmář wrote:
KVM_CAP_X2APIC_API can be enabled to extend APIC ID in get/set ioctl and MSI
addresses to 32 bits. Both are needed to support x2APIC.
The capability has to be toggleable and disabled by default, because get/set
ioctl shifted and truncated APIC ID to 8 bits
On 2016/7/8 1:15, Radim Krčmář wrote:
x2APIC supports up to 2^32-1 LAPICs, but most guest in coming years will
have slighly less VCPUs. Dynamic size saves memory at the cost of
turning one constant into a variable.
apic_map mutex had to be moved before allocation to avoid races with cpu
hotplug
On 2016/7/11 15:44, Paolo Bonzini wrote:
On 11/07/2016 08:06, Yang Zhang wrote:
Changes to MSI addresses follow the format used by interrupt remapping
unit.
The upper address word, that used to be 0, contains upper 24 bits of
the LAPIC
address in its upper 24 bits. Lower 8 bits are reserved
On 2016/7/11 15:43, Paolo Bonzini wrote:
On 11/07/2016 08:07, Yang Zhang wrote:
mutex_lock(&kvm->arch.apic_map_lock);
+kvm_for_each_vcpu(i, vcpu, kvm)
+if (kvm_apic_present(vcpu))
+max_id = max(max_id, kvm_apic_id(vcpu->arch.apic));
+
+new = kzal
On 2016/7/11 17:17, Paolo Bonzini wrote:
On 11/07/2016 10:56, Yang Zhang wrote:
On 2016/7/11 15:44, Paolo Bonzini wrote:
On 11/07/2016 08:06, Yang Zhang wrote:
Changes to MSI addresses follow the format used by interrupt remapping
unit.
The upper address word, that used to be 0, contains
On 2016/7/11 23:52, Radim Krčmář wrote:
2016-07-11 16:14+0200, Paolo Bonzini:
On 11/07/2016 15:48, Radim Krčmář wrote:
I guess the easiest solution is to replace kvm_apic_id with a field in
struct kvm_lapic, which is already shifted right by 24 in xAPIC mode.
(I guess the fewest LOC is to loo
On 2016/3/11 20:09, Paolo Bonzini wrote:
Sorry for the late reply.
On 11/03/2016 03:37, Yang Zhang wrote:
@@ -97,7 +104,7 @@ int kvm_update_cpuid(struct kvm_vcpu *vcpu)
if (best && (best->eax & (F(XSAVES) | F(XSAVEC
best->ebx = xstate_
On 2015/12/23 3:52, rkrc...@redhat.com wrote:
2015-12-22 07:19+, Wu, Feng:
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
On 2015/12/22 14:59, Wu, Feng wrote:
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
On 2015/12/16 9:37, Feng Wu wrote
On 2015/12/16 9:37, Feng Wu wrote:
Use vector-hashing to deliver lowest-priority interrupts, As an
example, modern Intel CPUs in server platform use this method to
handle lowest-priority interrupts.
Signed-off-by: Feng Wu
---
arch/x86/kvm/irq_comm.c | 27 ++-
arch/x86/kvm
On 2015/12/16 9:37, Feng Wu wrote:
Use vector-hashing to deliver lowest-priority interrupts for
VT-d posted-interrupts.
Signed-off-by: Feng Wu
---
arch/x86/kvm/lapic.c | 67
arch/x86/kvm/lapic.h | 2 ++
arch/x86/kvm/vmx.c | 12
On 2015/12/21 9:55, Wu, Feng wrote:
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Yang Zhang
Sent: Monday, December 21, 2015 9:50 AM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: k...@vger.kernel.org
On 2015/12/21 9:50, Wu, Feng wrote:
-Original Message-
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
Sent: Monday, December 21, 2015 9:46 AM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2
On 2015/12/22 12:36, Wu, Feng wrote:
-Original Message-
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
Sent: Monday, December 21, 2015 10:01 AM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2
On 2015/12/22 12:37, Wu, Feng wrote:
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Yang Zhang
Sent: Monday, December 21, 2015 10:06 AM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: k
On 2015/12/22 14:59, Wu, Feng wrote:
-Original Message-
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
Sent: Tuesday, December 22, 2015 2:49 PM
To: Wu, Feng ; pbonz...@redhat.com;
rkrc...@redhat.com
Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org; Jiang Liu
(jiang
On 2016/1/27 2:22, rkrc...@redhat.com wrote:
2016-01-26 09:44+0800, Yang Zhang:
On 2016/1/25 21:59, rkrc...@redhat.com wrote:
2016-01-25 09:49+0800, Yang Zhang:
On 2016/1/22 21:31, rkrc...@redhat.com wrote:
2016-01-22 10:03+0800, Yang Zhang:
Not so complicated. We can reuse the wake up
On 2016/1/22 21:31, rkrc...@redhat.com wrote:
2016-01-22 10:03+0800, Yang Zhang:
On 2016/1/22 0:35, rkrc...@redhat.com wrote:
2016-01-21 13:44+0800, Yang Zhang:
On 2016/1/21 13:41, Wu, Feng wrote:
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
We may have different understanding on PI
On 2016/1/25 21:59, rkrc...@redhat.com wrote:
2016-01-25 09:49+0800, Yang Zhang:
On 2016/1/22 21:31, rkrc...@redhat.com wrote:
2016-01-22 10:03+0800, Yang Zhang:
Not so complicated. We can reuse the wake up vector and check whether the
interrupt is multicast when one of destination vcpu
On 2017/6/23 11:58, Yang Zhang wrote:
On 2017/6/22 19:51, Paolo Bonzini wrote:
On 22/06/2017 13:22, root wrote:
==
+poll_grow: (X86 only)
+
+This parameter is multiplied in the grow_poll_ns() to increase the
poll time.
+By default
On 2017/7/4 22:13, Radim Krčmář wrote:
2017-07-03 17:28+0800, Yang Zhang:
The background is that we(Alibaba Cloud) do get more and more complaints
from our customers in both KVM and Xen compare to bare-mental.After
investigations, the root cause is known to us: big cost in message passing
On 2017/7/14 17:37, Alexander Graf wrote:
On 13.07.17 13:49, Yang Zhang wrote:
On 2017/7/4 22:13, Radim Krčmář wrote:
2017-07-03 17:28+0800, Yang Zhang:
The background is that we(Alibaba Cloud) do get more and more
complaints
from our customers in both KVM and Xen compare to bare
On 2017/7/17 17:54, Alexander Graf wrote:
On 17.07.17 11:26, Yang Zhang wrote:
On 2017/7/14 17:37, Alexander Graf wrote:
On 13.07.17 13:49, Yang Zhang wrote:
On 2017/7/4 22:13, Radim Krčmář wrote:
2017-07-03 17:28+0800, Yang Zhang:
The background is that we(Alibaba Cloud) do get more
On 2017/8/29 22:56, Michael S. Tsirkin wrote:
On Tue, Aug 29, 2017 at 11:46:34AM +, Yang Zhang wrote:
Some latency-intensive workload will see obviously performance
drop when running inside VM.
But are we trading a lot of CPU for a bit of lower latency?
The main reason is that the
.update is used to adjust the next poll time.
Signed-off-by: Yang Zhang
Signed-off-by: Quan Xu
Cc: Jeremy Fitzhardinge
Cc: Chris Wright
Cc: Alok Kataria
Cc: Rusty Russell
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Andy
its/s -- 157.6 %CPU
V1 -> V2:
- integrate the smart halt poll into paravirt code
- use idle_stamp instead of check_poll
- since it hard to get whether vcpu is the only task in pcpu, so we
don't consider it in this series.(May improve it in future)
Yang Zhang (7):
x86/paravirt: Add p
Add poll in do_idle. For UP VM, if there are running task, it will not
goes into idle path, so we only enable poll in SMP VM.
Signed-off-by: Yang Zhang
Signed-off-by: Quan Xu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Boris
that idle_stamp only used when using CFS scheduler. But
it is ok since it is the default policy for scheduler and only consider
it should enough.
Signed-off-by: Yang Zhang
Signed-off-by: Quan Xu
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: linux-kernel@vger.kernel.org
---
include/linux/sched/idle.h | 4
using smart idle poll to reduce the useless poll when system is idle.
Signed-off-by: Yang Zhang
Signed-off-by: Quan Xu
Cc: Paolo Bonzini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
To reduce the cost of poll, we introduce three sysctl to control the
poll time.
Signed-off-by: Yang Zhang
Signed-off-by: Quan Xu
Cc: Jonathan Corbet
Cc: Jeremy Fitzhardinge
Cc: Chris Wright
Cc: Alok Kataria
Cc: Rusty Russell
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin&qu
-off-by: Yang Zhang
Signed-off-by: Quan Xu
Cc: Paolo Bonzini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
arch/x86/kernel/kvm.c | 26 ++
1 file changed, 26 insertion
cause the CPU waste so we adopt a smart polling mechanism to
reduce the useless poll.
Signed-off-by: Yang Zhang
Signed-off-by: Quan Xu
Cc: Jeremy Fitzhardinge
Cc: Chris Wright
Cc: Alok Kataria
Cc: Rusty Russell
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@ker
On 2017/8/24 5:26, Paolo Bonzini wrote:
Move it to struct kvm_arch_vcpu, replacing guest_pkru_valid with a
simple comparison against the host value of the register.
Thanks for refine the patches.:)
Signed-off-by: Paolo Bonzini
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/kvm_
On 2017/8/24 17:19, Paolo Bonzini wrote:
On 24/08/2017 11:09, Yang Zhang wrote:
+if (static_cpu_has(X86_FEATURE_OSPKE) &&
We expose protection key to VM without check whether OSPKE is enabled or
not. Why not check guest's cpuid here which also can avoid unnecessary
a
On 2017/8/24 18:12, Paolo Bonzini wrote:
The host pkru is restored right after vcpu exit (commit 1be0e61), so
KVM_GET_XSAVE will return the host PKRU value instead. In general,
the PKRU value in vcpu->arch.guest_fpu.state cannot be trusted.
Series as follows:
1) fix independent bug which would
les changed, 28 insertions(+), 37 deletions(-)
Reviewed-by: Yang Zhang
--
Yang
Alibaba Cloud Computing
On 2017/8/29 19:58, Alexander Graf wrote:
On 08/29/2017 01:46 PM, Yang Zhang wrote:
Some latency-intensive workload will see obviously performance
drop when running inside VM. The main reason is that the overhead
is amplified when running inside VM. The most cost i have seen is
inside idle path
On 2017/8/29 22:02, Wanpeng Li wrote:
Here is the data we get when running benchmark netperf:
2. w/ patch:
halt_poll_threshold=1 -- 15803.89 bits/s -- 159.5 %CPU
halt_poll_threshold=2 -- 15899.04 bits/s -- 161.5 %CPU
halt_poll_threshold=3 -- 15642.38 bits/s -
On 2017/8/29 22:02, Wanpeng Li wrote:
Here is the data we get when running benchmark netperf:
2. w/ patch:
halt_poll_threshold=1 -- 15803.89 bits/s -- 159.5 %CPU
halt_poll_threshold=2 -- 15899.04 bits/s -- 161.5 %CPU
halt_poll_threshold=3 -- 15642.38 bits/s -
On 2017/8/29 21:55, Konrad Rzeszutek Wilk wrote:
On Tue, Aug 29, 2017 at 11:46:35AM +, Yang Zhang wrote:
So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called in
idle path which will polling for a while before we enter the real idle
state.
In virtualization, idle path
On 2017/8/29 20:46, Peter Zijlstra wrote:
On Tue, Aug 29, 2017 at 11:46:41AM +, Yang Zhang wrote:
In ttwu_do_wakeup, it will update avg_idle when wakeup from idle. Here
we just reuse this logic to update the poll time. It may be a little
late to update the poll in ttwu_do_wakeup, but the
On 2017/9/1 14:58, Wanpeng Li wrote:
2017-09-01 14:44 GMT+08:00 Yang Zhang :
On 2017/8/29 22:02, Wanpeng Li wrote:
Here is the data we get when running benchmark netperf:
2. w/ patch:
halt_poll_threshold=1 -- 15803.89 bits/s -- 159.5 %CPU
halt_poll_threshold=2
On 2017/6/22 19:51, Paolo Bonzini wrote:
On 22/06/2017 13:22, root wrote:
==
+poll_grow: (X86 only)
+
+This parameter is multiplied in the grow_poll_ns() to increase the poll time.
+By default, the values is 2.
+
+==
On 2017/6/22 22:32, Thomas Gleixner wrote:
On Thu, 22 Jun 2017, root wrote:
@@ -962,6 +962,7 @@ __visible void __irq_entry smp_apic_timer_interrupt(struct
pt_regs *regs)
* interrupt lock, which is the WrongThing (tm) to do.
*/
entering_ack_irq();
+ check_poll();
On 2017/6/22 22:23, Thomas Gleixner wrote:
On Thu, 22 Jun 2017, root wrote:
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -39,6 +39,10 @@
#include
#include
+#ifdef CONFIG_HYPERVISOR_GUEST
+unsigned long poll_threshold_ns;
+#endif
+
/*
* per-CPU TSS segments. Threads
On 2017/6/22 19:50, Wanpeng Li wrote:
2017-06-22 19:22 GMT+08:00 root :
From: Yang Zhang
Some latency-intensive workload will see obviously performance
drop when running inside VM. The main reason is that the overhead
is amplified when running inside VM. The most cost i have seen is
inside
On 2017/6/23 12:35, Wanpeng Li wrote:
2017-06-23 12:08 GMT+08:00 Yang Zhang :
On 2017/6/22 19:50, Wanpeng Li wrote:
2017-06-22 19:22 GMT+08:00 root :
From: Yang Zhang
Some latency-intensive workload will see obviously performance
drop when running inside VM. The main reason is that the
On 2017/6/27 22:22, Radim Krčmář wrote:
2017-06-27 15:56+0200, Paolo Bonzini:
On 27/06/2017 15:40, Radim Krčmář wrote:
... which is not necessarily _wrong_. It's just a different heuristic.
Right, it's just harder to use than host's single_task_running() -- the
VCPU calling vcpu_is_preempted(
On 2017/7/3 18:06, Thomas Gleixner wrote:
On Mon, 3 Jul 2017, Yang Zhang wrote:
The background is that we(Alibaba Cloud) do get more and more complaints from
our customers in both KVM and Xen compare to bare-mental.After investigations,
the root cause is known to us: big cost in message passing
On 2016/9/28 5:20, Paolo Bonzini wrote:
Since bf9f6ac8d749 ("KVM: Update Posted-Interrupts Descriptor when vCPU
is blocked", 2015-09-18) the posted interrupt descriptor is checked
unconditionally for PIR.ON. Therefore we don't need KVM_REQ_EVENT to
trigger the scan and, if NMIs or SMIs are not i
On 2016/9/28 5:20, Paolo Bonzini wrote:
Calling apic_find_highest_irr results in IRR being scanned twice,
once in vmx_sync_pir_from_irr and once in apic_search_irr. Change
vcpu_enter_guest to use sync_pir_from_irr (with a new argument to
trigger the RVI write), and let sync_pir_from_irr get the
On 2016/9/28 19:50, Paolo Bonzini wrote:
On 28/09/2016 13:40, Wu, Feng wrote:
IIUIC, the issue you describe above is that IPI for posted-interrupts may be
issued between
vcpu->mode = IN_GUEST_MODE;
and
local_irq_disable();
But if that really happens, we will call kvm_vcpu_kick() in
vmx_del
92 matches
Mail list logo
