On Thu, 20 Jun 2019 at 05:04, Marcelo Tosatti wrote:
>
> Hi Li,
>
> On Wed, Jun 19, 2019 at 08:36:06AM +0800, Wanpeng Li wrote:
> > On Tue, 18 Jun 2019 at 21:36, Marcelo Tosatti wrote:
> > >
> > > On Mon, Jun 17, 2019 at 07:24:44PM +0800, Wanpen
On Thu, 20 Jun 2019 at 20:38, Peter Zijlstra wrote:
>
> On Thu, Jun 20, 2019 at 07:36:54PM +0800, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > In real product setup, there will be houseeking cpus in each nodes, it
> > is prefer to do housekeeping from local n
From: Wanpeng Li
In real product setup, there will be houseeking cpus in each nodes, it
is prefer to do housekeeping from local node, fallback to global online
cpumask if failed to find houseeking cpu from local node.
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Signed-off
mean this part about XSS_EXIT_BITMAP? how about the other part in
> > vmx_set/get_msr() in this patch?
>
> Yes, only the XSS_EXIT_BITMAP part. The other is a bugfix, I didn't
> understand Wanpeng's objection very well.
https://lkml.org/lkml/2019/6/20/227 A more complete one.
Regards,
Wanpeng Li
From: Wanpeng Li
Raise #GP when guest read/write forbidden IA32_XSS.
Fixes: 203000993de5 (kvm: vmx: add MSR logic for XSAVES)
Reported-by: Xiaoyao Li
Reported-by: Tao Xu
Cc: Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: sta...@vger.kernel.org
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/vmx
cpuid_update() in
kvm_vcpu_reset() path to reflect the new guest cpuid influence to
exec_control? e.g. the first boot guest disable xsaves in grub, kvm
disables xsaves in exec_control; then guest reboot w/ xsaves enabled,
it still get an #UD when executing.
Regards,
Wanpeng Li
S-exiting bitmap.
It depends on whether or not processors support the 1-setting instead
of “enable XSAVES/XRSTORS” is 1 in VM-exection control field. Anyway,
I will send a patch to fix the msr read/write for commit
203000993de5(kvm: vmx: add MSR logic for XSAVES), thanks for the
report.
Regards,
Wanpeng Li
On Thu, 20 Jun 2019 at 05:04, Marcelo Tosatti wrote:
>
> Hi Li,
>
> On Wed, Jun 19, 2019 at 08:36:06AM +0800, Wanpeng Li wrote:
> > On Tue, 18 Jun 2019 at 21:36, Marcelo Tosatti wrote:
> > >
> > > On Mon, Jun 17, 2019 at 07:24:44PM +0800, Wanpen
Cc Frederic,
On Tue, 18 Jun 2019 at 11:13, Wanpeng Li wrote:
>
> From: Wanpeng Li
>
> On a machine, cpu 0 is used for housekeeping, other 39 cpus are in
> nohz_full mode. We can observe huge time burn in the loop for seaching
> nearest busy housekeeper cpu
On Tue, 18 Jun 2019 at 21:36, Marcelo Tosatti wrote:
>
> On Mon, Jun 17, 2019 at 07:24:44PM +0800, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > Dedicated instances are currently disturbed by unnecessary jitter due
> > to the emulated lapic timers fire on the s
ping, :)
On Tue, 11 Jun 2019 at 20:23, Wanpeng Li wrote:
>
> The idea is from Xen, when sending a call-function IPI-many to vCPUs,
> yield if any of the IPI target vCPUs was preempted. 17% performance
> increasement of ebizzy benchmark can be observed in an over-subscribe
> envir
From: Wanpeng Li
On a machine, cpu 0 is used for housekeeping, other 39 cpus are in
nohz_full mode. We can observe huge time burn in the loop for seaching
nearest busy housekeeper cpu by ftrace.
2) |get_nohz_timer_target() {
2) 0.240 us
On Tue, 18 Jun 2019 at 08:44, Wanpeng Li wrote:
>
> On Tue, 18 Jun 2019 at 05:32, Radim Krčmář wrote:
> >
> > 2019-06-17 19:24+0800, Wanpeng Li:
> > > From: Wanpeng Li
> > >
> > > Wait before calling posted-interrupt deliver functio
On Tue, 18 Jun 2019 at 05:32, Radim Krčmář wrote:
>
> 2019-06-17 19:24+0800, Wanpeng Li:
> > From: Wanpeng Li
> >
> > Wait before calling posted-interrupt deliver function directly to add
> > advance timer support to pi_inject_timer.
> >
> > Cc: P
On Mon, 17 Jun 2019 at 19:48, Peter Xu wrote:
>
> On Mon, Jun 17, 2019 at 07:24:43PM +0800, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > Make lapic timer unpinned when timer is injected by posted-interrupt,
>
> It has nothing to do with PI, yet?
>
>
From: Wanpeng Li
Dedicated instances are currently disturbed by unnecessary jitter due
to the emulated lapic timers fire on the same pCPUs which vCPUs resident.
There is no hardware virtual timer on Intel for guest like ARM. Both
programming timer in guest and the emulated timer fires incur
From: Wanpeng Li
Wait before calling posted-interrupt deliver function directly to add
advance timer support to pi_inject_timer.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Marcelo Tosatti
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/lapic.c | 6 --
arch/x86/kvm/lapic.h | 2 +-
arch/x86
From: Wanpeng Li
When lapic timer is injected by posted-interrupt, the emulated timer is
offload to the housekeeping cpu. The timer interrupt will be delivered
properly, no need to migrate timer.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Marcelo Tosatti
Signed-off-by: Wanpeng Li
---
arch/x86
-> v2:
* check vcpu_halt_in_guest
* move module parameter from kvm-intel to kvm
* add housekeeping_enabled
* rename apic_timer_expired_pi to kvm_apic_inject_pending_timer_irqs
Wanpeng Li (5):
KVM: LAPIC: Make lapic timer unpinned
KVM: LAPIC: inject lapic timer interrupt by posted int
From: Wanpeng Li
already-expired timer interrupt can be injected to guest when vCPU who
arms the lapic timer re-vmentry, don't posted inject in this case.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Marcelo Tosatti
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/lapic.c | 14 +++---
1 file
From: Wanpeng Li
Make lapic timer unpinned when timer is injected by posted-interrupt,
the emulated timer can be offload to the housekeeping cpus, kick after
setting the pending timer request as alternative to commit 61abdbe0bcc.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Marcelo Tosatti
Signed
From: Wanpeng Li
Advance lapic timer tries to hidden the hypervisor overhead between the
host emulated timer fires and the guest awares the timer is fired. However,
even though after more sustaining optimizations,
kvm-unit-tests/tscdeadline_latency
still awares ~1000 cycles latency since we
From: Wanpeng Li
The trailing newlines will lead to extra newlines in the trace file
which looks like the following output, so remove it.
qemu-system-x86-15695 [002] ...1 15774.839240: kvm_hv_timer_state: vcpu_id 0
hv_timer 1
qemu-system-x86-15695 [002] ...1 15774.839309: kvm_hv_timer_state
On Thu, 13 Jun 2019 at 00:01, Sean Christopherson
wrote:
>
> On Tue, Jun 11, 2019 at 03:34:07PM +0800, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > Dynamic allocate core residency msr state. MSR_CORE_C1_RES is unreadable
> > except for ATOM platform, so it is
On Thu, 13 Jun 2019 at 03:27, Radim Krčmář wrote:
>
> 2019-06-12 21:22+0200, Radim Krčmář:
> > 2019-06-12 08:14-0700, Sean Christopherson:
> > > On Wed, Jun 12, 2019 at 05:40:18PM +0800, Wanpeng Li wrote:
> > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kv
On Wed, 12 Jun 2019 at 23:14, Sean Christopherson
wrote:
>
> On Wed, Jun 12, 2019 at 05:40:18PM +0800, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > Advance lapic timer tries to hidden the hypervisor overhead between the
> > host emulated timer fires and the g
On Thu, 13 Jun 2019 at 15:59, Maxim Levitsky wrote:
>
> On Tue, 2019-06-11 at 20:17 +0800, Wanpeng Li wrote:
> > Dedicated instances are currently disturbed by unnecessary jitter due
> > to the emulated lapic timers fire on the same pCPUs which vCPUs resident.
> > Ther
Sorry, send out the wrong patchset, please ignore.
On Wed, 12 Jun 2019 at 17:36, Wanpeng Li wrote:
>
> Advance lapic timer tries to hidden the hypervisor overhead between the
> host emulated timer fires and the guest awares the timer is fired. However,
> it just hidden the
From: Wanpeng Li
The trailing newlines will lead to extra newlines in the trace file
which looks like the following output, so remove it.
qemu-system-x86-15695 [002] ...1 15774.839240: kvm_hv_timer_state: vcpu_id 0
hv_timer 1
qemu-system-x86-15695 [002] ...1 15774.839309: kvm_hv_timer_state
From: Wanpeng Li
Advance lapic timer tries to hidden the hypervisor overhead between the
host emulated timer fires and the guest awares the timer is fired. However,
even though after more sustaining optimizations,
kvm-unit-tests/tscdeadline_latency
still awares ~1000 cycles latency since we
sc_khz().
>
> I would just make it read-only. But I'm afraid we're entering somewhat
> dangerous territory. There is a risk that the guest ends up entering
> the interrupt handler before the TSC deadline has actually expired, and
> there would be no way to know what would happen; even guest hangs are
> possible.
Agreed, do it in v3.
Regards,
Wanpeng Li
ose by debugfs
* move the call to wait_lapic_expire() into vmx.c and svm.c
Wanpeng Li (5):
KVM: LAPIC: Extract adaptive tune timer advancement logic
KVM: LAPIC: Fix lapic_timer_advance_ns parameter overflow
KVM: LAPIC: Expose per-vCPU timer_advance_ns to userspace
KVM: LAPIC: Delay trace adva
From: Wanpeng Li
wait_lapic_expire() call was moved above guest_enter_irqoff() because of
its tracepoint, which violated the RCU extended quiescent state invoked
by guest_enter_irqoff()[1][2]. This patch simply moves the tracepoint
below guest_exit_irqoff() in vcpu_enter_guest(). Snapshot
From: Wanpeng Li
After commit c3941d9e0 (KVM: lapic: Allow user to disable adaptive tuning of
timer advancement), '-1' enables adaptive tuning starting from default
advancment of 1000ns. However, we should expose an int instead of an overflow
uint module parameter.
Before patch:
/sys/module
From: Wanpeng Li
Extract adaptive tune timer advancement logic to a single function.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Sean Christopherson
Cc: Liran Alon
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/lapic.c | 57 ++--
1 file changed, 33
From: Wanpeng Li
Advance lapic timer tries to hidden the hypervisor overhead between the
host emulated timer fires and the guest awares the timer is fired. However,
it just hidden the time between apic_timer_fn/handle_preemption_timer ->
wait_lapic_expire, instead of the real posit
From: Wanpeng Li
Expose per-vCPU timer_advance_ns to userspace, so it is able to
query the auto-adjusted value.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Sean Christopherson
Cc: Liran Alon
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/debugfs.c | 16
1 file changed, 16
On Tue, 11 Jun 2019 at 09:21, Sean Christopherson
wrote:
>
> On Fri, May 31, 2019 at 02:40:13PM +0800, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > Advance lapic timer tries to hidden the hypervisor overhead between the
> > host emulated timer fires and the g
On Tue, 11 Jun 2019 at 19:09, Paolo Bonzini wrote:
>
> On 11/06/19 09:38, Wanpeng Li wrote:
> > MSR_CORE_C1_RES is unreadable except for ATOM platform, so I think we
> > can avoid the complex logic to handle C1 now. :)
>
> I disagree. Linux uses it on all platforms i
On Wed, 12 Jun 2019 at 04:39, Marcelo Tosatti wrote:
>
> On Tue, Jun 11, 2019 at 08:17:07PM +0800, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > Dedicated instances are currently disturbed by unnecessary jitter due
> > to the emulated lapic timers fire on the s
On Wed, 12 Jun 2019 at 00:57, Nadav Amit wrote:
>
> > On Jun 11, 2019, at 3:02 AM, Wanpeng Li wrote:
> >
> > On Tue, 11 Jun 2019 at 09:48, Nadav Amit wrote:
> >>> On Jun 10, 2019, at 6:45 PM, Wanpeng Li wrote:
> >>>
> >>> On Tu
On Wed, 12 Jun 2019 at 04:39, Marcelo Tosatti wrote:
>
> On Tue, Jun 11, 2019 at 08:17:06PM +0800, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > Make lapic timer unpinned when timer is injected by posted-interrupt,
> > the emulated timer can be offload to the house
From: Wanpeng Li
Expose PV_SCHED_YIELD feature bit to guest, the guest can check this
feature bit before using paravirtualized sched yield.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Liran Alon
Signed-off-by: Wanpeng Li
---
Documentation/virtual/kvm/cpuid.txt | 4
arch/x86/kvm/cpuid.c
ed_yield static
* change dest_id to unsinged long
Wanpeng Li (3):
KVM: X86: Yield to IPI target if necessary
KVM: X86: Implement PV sched yield hypercall
KVM: X86: Expose PV_SCHED_YIELD CPUID feature bit to guest
Documentation/virtual/kvm/cpuid.txt | 4
Documentation/virtual/kvm/hype
From: Wanpeng Li
The target vCPUs are in runnable state after vcpu_kick and suitable
as a yield target. This patch implements the sched yield hypercall.
17% performance increasement of ebizzy benchmark can be observed in an
over-subscribe environment. (w/ kvm-pv-tlb disabled, testing TLB
From: Wanpeng Li
When sending a call-function IPI-many to vCPUs, yield if any of
the IPI target vCPUs was preempted, we just select the first
preempted target vCPU which we found since the state of target
vCPUs can change underneath and to avoid race conditions.
Cc: Paolo Bonzini
Cc: Radim
From: Wanpeng Li
Make lapic timer unpinned when timer is injected by posted-interrupt,
the emulated timer can be offload to the housekeeping cpus.
The host admin should fine tuned, e.g. dedicated instances scenario
w/ nohz_full cover the pCPUs which vCPUs resident, several pCPUs
surplus
From: Wanpeng Li
When lapic timer is injected by posted-interrupt, the emulated timer is
offload to the housekeeping cpu. The timer interrupt will be delivered
properly, no need to migrate timer.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/lapic.c | 3
timer_expired_pi to kvm_apic_inject_pending_timer_irqs
Wanpeng Li (4):
KVM: LAPIC: Make lapic timer unpinned when timer is injected by pi
KVM: LAPIC: lapic timer interrupt is injected by posted interrupt
KVM: LAPIC: Ignore timer migration when lapic timer is injected by pi
KVM: LAPIC: add advan
From: Wanpeng Li
Dedicated instances are currently disturbed by unnecessary jitter due
to the emulated lapic timers fire on the same pCPUs which vCPUs resident.
There is no hardware virtual timer on Intel for guest like ARM. Both
programming timer in guest and the emulated timer fires incur
On Tue, 11 Jun 2019 at 19:40, Paolo Bonzini wrote:
>
> On 06/06/19 07:31, Wanpeng Li wrote:
> > +static inline bool can_posted_interrupt_inject_timer(struct kvm_vcpu *vcpu)
> > +{
> > + return posted_interrupt_inject_timer_enabled(vcpu) &&
> >
From: Wanpeng Li
Wait before calling posted-interrupt deliver function directly to add
advance timer support to pi_inject_timer.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/lapic.c | 6 --
arch/x86/kvm/lapic.h | 2 +-
arch/x86/kvm/svm.c | 2
On Tue, 11 Jun 2019 at 19:09, Paolo Bonzini wrote:
>
> On 11/06/19 09:38, Wanpeng Li wrote:
> > MSR_CORE_C1_RES is unreadable except for ATOM platform, so I think we
> > can avoid the complex logic to handle C1 now. :)
>
> I disagree. Linux uses it on all platforms i
On Mon, 10 Jun 2019 at 22:34, Radim Krčmář wrote:
>
> 2019-05-30 09:05+0800, Wanpeng Li:
> > The idea is from Xen, when sending a call-function IPI-many to vCPUs,
> > yield if any of the IPI target vCPUs was preempted. 17% performance
> > increasement of ebizzy b
On Tue, 11 Jun 2019 at 09:48, Nadav Amit wrote:
>
> > On Jun 10, 2019, at 6:45 PM, Wanpeng Li wrote:
> >
> > On Tue, 11 Jun 2019 at 09:11, Sean Christopherson
> > wrote:
> >> On Mon, Jun 10, 2019 at 04:34:20PM +0200, Radim Krčmář wrote:
> >>> 20
On Mon, 10 Jun 2019 at 22:17, Radim Krčmář wrote:
>
> 2019-05-30 09:05+0800, Wanpeng Li:
> > From: Wanpeng Li
> >
> > The target vCPUs are in runnable state after vcpu_kick and suitable
> > as a yield target. This patch implements the sched yield hypercall.
> &
On Tue, 11 Jun 2019 at 07:51, Naoya Horiguchi wrote:
>
> On Wed, May 29, 2019 at 04:31:01PM -0700, Mike Kravetz wrote:
> > On 5/28/19 2:49 AM, Wanpeng Li wrote:
> > > Cc Paolo,
> > > Hi all,
> > > On Wed, 14 Feb 2018 at 06:34, Mike Kravetz
> >
On Tue, 11 Jun 2019 at 01:11, Radim Krčmář wrote:
>
> 2019-06-06 13:31+0800, Wanpeng Li:
> > From: Wanpeng Li
> >
> > Make lapic timer unpinned when timer is injected by posted-interrupt,
> > the emulated timer can be offload to the housekeeping cpus.
> >
On Tue, 11 Jun 2019 at 00:51, Radim Krčmář wrote:
>
> 2019-06-06 13:31+0800, Wanpeng Li:
> > From: Wanpeng Li
> >
> > Dedicated instances are currently disturbed by unnecessary jitter due
> > to the emulated lapic timers fire on the same pCPUs which vCPUs resi
On Wed, 5 Jun 2019 at 00:53, Paolo Bonzini wrote:
>
> On 21/05/19 08:06, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > Allow guest reads CORE cstate when exposing host CPU power management
> > capabilities
> > to the guest. PKG cstate is restrict
power management capabilities
to the guest. PKG cstate is restricted currently to avoid a guest to get
the whole package information in multi-tenant scenario.
v1 -> v2:
* add residency msrs emulation (base on Paolo's design)
Wanpeng Li (5):
KVM: X86: Dynamic allocate core residency msr st
From: Wanpeng Li
To save/restore residency values when vCPU migrates between mulitple
pCPUs.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/arm/include/asm/kvm_host.h | 1 +
arch/arm64/include/asm/kvm_host.h | 1 +
arch/mips/include/asm/kvm_host.h| 1
From: Wanpeng Li
Both live migration and vCPU migrates between pCPUs possibly to set the MSRs
in the host to change the delta between the host and guest values. This patch
introduces msrs read/write operations in the host.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
From: Wanpeng Li
Dynamic allocate core residency msr state. MSR_CORE_C1_RES is unreadable
except for ATOM platform, so it is ignore here.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/x86/include/asm/kvm_host.h | 11 +++
arch/x86/kvm/vmx/vmx.c | 5
From: Wanpeng Li
To setup core residency msrs during vCPU creation. Allowing guest reads
CORE cstate when exposing host CPU power management capabilities to the
guest. PKG cstate is restricted currently to avoid a guest to get the
whole package information in multi-tenant scenario.
Cc: Paolo
From: Wanpeng Li
Add logic to get/set the residency msrs. Then current idle
power-state residency statistics can be consult by guest, and
be save/restore during live migration.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/vmx/vmx.c | 8
1 file
On Tue, 11 Jun 2019 at 09:11, Sean Christopherson
wrote:
>
> On Mon, Jun 10, 2019 at 04:34:20PM +0200, Radim Krčmář wrote:
> > 2019-05-30 09:05+0800, Wanpeng Li:
> > > The idea is from Xen, when sending a call-function IPI-many to vCPUs,
> > > yield if any of the
On Tue, 11 Jun 2019 at 09:21, Sean Christopherson
wrote:
>
> On Fri, May 31, 2019 at 02:40:13PM +0800, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > Advance lapic timer tries to hidden the hypervisor overhead between the
> > host emulated timer fires and the g
ping, :)
On Thu, 30 May 2019 at 09:05, Wanpeng Li wrote:
>
> The idea is from Xen, when sending a call-function IPI-many to vCPUs,
> yield if any of the IPI target vCPUs was preempted. 17% performance
> increasement of ebizzy benchmark can be observed in an over-subscribe
> envir
On Thu, 6 Jun 2019 at 13:31, Wanpeng Li wrote:
>
> Dedicated instances are currently disturbed by unnecessary jitter due
> to the emulated lapic timers fire on the same pCPUs which vCPUs resident.
> There is no hardware virtual timer on Intel for guest like ARM. Both
> programming
From: Wanpeng Li
Wait before calling posted-interrupt deliver function directly to add
advance timer support to pi_inject_timer.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/lapic.c | 6 --
arch/x86/kvm/lapic.h | 2 +-
arch/x86/kvm/svm.c | 2
On Wed, 5 Jun 2019 at 21:04, Paolo Bonzini wrote:
>
> On 05/06/19 12:09, Wanpeng Li wrote:
> > +static inline bool posted_interrupt_inject_timer(struct kvm_vcpu *vcpu)
> > +{
> > + return (kvm_x86_ops->pi_inject_timer_enabled(vcpu) &&
> > +
On Wed, 5 Jun 2019 at 20:30, Paolo Bonzini wrote:
>
> On 05/06/19 12:09, Wanpeng Li wrote:
> > +static void apic_timer_expired_pi(struct kvm_lapic *apic)
> > +{
> > + struct kvm_timer *ktimer = >lapic_timer;
> > +
> > +
From: Wanpeng Li
Dedicated instances are currently disturbed by unnecessary jitter due
to the emulated lapic timers fire on the same pCPUs which vCPUs resident.
There is no hardware virtual timer on Intel for guest like ARM. Both
programming timer in guest and the emulated timer fires incur
From: Wanpeng Li
Make lapic timer unpinned when timer is injected by posted-interrupt,
the emulated timer can be offload to the housekeeping cpus.
The host admin should fine tuned, e.g. dedicated instances scenario
w/ nohz_full cover the pCPUs which vCPUs resident, several pCPUs
surplus
From: Wanpeng Li
When lapic timer is injected by posted-interrupt, the emulated timer is
offload to the housekeeping cpu. The timer interrupt will be delivered
properly, no need to migrate timer.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/lapic.c | 3
arameter from kvm-intel to kvm
* add housekeeping_enabled
* rename apic_timer_expired_pi to kvm_apic_inject_pending_timer_irqs
Wanpeng Li (3):
KVM: LAPIC: Make lapic timer unpinned when timer is injected by
posted-interrupt
KVM: LAPIC: lapic timer interrupt is injected by posted interrupt
On Wed, 5 Jun 2019 at 00:59, Paolo Bonzini wrote:
>
> On 21/05/19 08:06, Wanpeng Li wrote:
> >
> > The CPUID.01H:ECX[bit 3] ought to mirror the value of the MSR bit,
> > CPUID.01H:ECX[bit 3] is a better guard than kvm_mwait_in_guest().
> > kvm_mwait_in_guest() a
On Wed, 5 Jun 2019 at 00:53, Paolo Bonzini wrote:
>
> On 21/05/19 08:06, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > Allow guest reads CORE cstate when exposing host CPU power management
> > capabilities
> > to the guest. PKG cstate is restrict
From: Wanpeng Li
When lapic timer is injected by posted-interrupt, the emulated timer is
offload to the housekeeping cpu. The timer interrupt will be delivered
properly, no need to migrate timer.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/lapic.c | 3
From: Wanpeng Li
Dedicated instances are currently disturbed by unnecessary jitter due
to the emulated lapic timers fire on the same pCPUs which vCPUs resident.
There is no hardware virtual timer on Intel for guest like ARM. Both
programming timer in guest and the emulated timer fires incur
e observed on Skylake server.
Wanpeng Li (3):
KVM: LAPIC: Make lapic timer unpinned when timer is injected by
posted-interrupt
KVM: LAPIC: lapic timer is injected by posted interrupt
KVM: LAPIC: Ignore timer migration when lapic timer is injected by
posted-interrupt
arch/x86/i
From: Wanpeng Li
Make lapic timer unpinned when timer is injected by posted-interrupt,
the emulated timer can be offload to the housekeeping cpus.
This patch introduces a new kvm module parameter, it is false by default.
The host admin can enable it after fine tuned, e.g. dedicated instances
On Fri, 31 May 2019 at 03:36, Sean Christopherson
wrote:
>
> On Thu, May 23, 2019 at 12:18:50PM +0800, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > Advance lapic timer tries to hidden the hypervisor overhead between the
> > host emulated timer fires and the g
From: Wanpeng Li
The trailing newlines will lead to extra newlines in the trace file
which looks like the following output, so remove it.
qemu-system-x86-15695 [002] ...1 15774.839240: kvm_hv_timer_state: vcpu_id 0
hv_timer 1
qemu-system-x86-15695 [002] ...1 15774.839309: kvm_hv_timer_state
From: Wanpeng Li
Advance lapic timer tries to hidden the hypervisor overhead between the
host emulated timer fires and the guest awares the timer is fired. However,
even though after more sustaining optimizations,
kvm-unit-tests/tscdeadline_latency
still awares ~1000 cycles latency since we
On Wed, 29 May 2019 at 20:28, Liran Alon wrote:
>
>
>
> > On 28 May 2019, at 3:53, Wanpeng Li wrote:
> >
> > From: Wanpeng Li
> >
> > The target vCPUs are in runnable state after vcpu_kick and suitable
> > as a yield target. This patch imp
From: Wanpeng Li
When sending a call-function IPI-many to vCPUs, yield if any of
the IPI target vCPUs was preempted, we just select the first
preempted target vCPU which we found since the state of target
vCPUs can change underneath and to avoid race conditions.
Cc: Paolo Bonzini
Cc: Radim
call-function is not easy to be trigged by userspace
workload).
v2 -> v3:
* add bounds-check on dest_id
v1 -> v2:
* check map is not NULL
* check map->phys_map[dest_id] is not NULL
* make kvm_sched_yield static
* change dest_id to unsinged long
Wanpeng Li (3):
KVM: X86: Yield to I
From: Wanpeng Li
The target vCPUs are in runnable state after vcpu_kick and suitable
as a yield target. This patch implements the sched yield hypercall.
17% performance increasement of ebizzy benchmark can be observed in an
over-subscribe environment. (w/ kvm-pv-tlb disabled, testing TLB
From: Wanpeng Li
Expose PV_SCHED_YIELD feature bit to guest, the guest can check this
feature bit before using paravirtualized sched yield.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Liran Alon
Signed-off-by: Wanpeng Li
---
Documentation/virtual/kvm/cpuid.txt | 4
arch/x86/kvm/cpuid.c
On Tue, 28 May 2019 at 17:12, Christian Borntraeger
wrote:
>
> On 28.05.19 02:53, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > The target vCPUs are in runnable state after vcpu_kick and suitable
> > as a yield target. This patch implements the sched yield hyp
We have a plan to split this 1GB hugetblfs page by 2MB
hugetlbfs pages/4KB pages, maybe file remap to a virtual address range
which is 2MB/4KB page granularity, also split the KVM MMU 1GB SPTE
into 2MB/4KB and mark the offensive SPTE w/ a hwpoison flag, a sigbus
will be delivered to VM at page fault next time for the offensive
SPTE. Is this proposal acceptable?
Regards,
Wanpeng Li
From: Wanpeng Li
Expose PV_SCHED_YIELD feature bit to guest, the guest can check this
feature bit before using paravirtualized sched yield.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
Documentation/virtual/kvm/cpuid.txt | 4
arch/x86/kvm/cpuid.c| 3
From: Wanpeng Li
The target vCPUs are in runnable state after vcpu_kick and suitable
as a yield target. This patch implements the sched yield hypercall.
17% performance increase of ebizzy benchmark can be observed in an
over-subscribe environment. (w/ kvm-pv-tlb disabled, testing TLB flush
-function is not easy to be trigged by userspace
workload).
v1 -> v2:
* check map is not NULL
* check map->phys_map[dest_id] is not NULL
* make kvm_sched_yield static
* change dest_id to unsinged long
Wanpeng Li (3):
KVM: X86: Implement PV sched yield in linux guest
KVM: X86: Implem
From: Wanpeng Li
When sending a call-function IPI-many to vCPUs, yield if any of
the IPI target vCPUs was preempted, we just select the first
preempted target vCPU which we found since the state of target
vCPUs can change underneath and to avoid race conditions.
Cc: Paolo Bonzini
Cc: Radim
-function is not easy to be trigged by userspace
workload).
v1 -> v2:
* check map is not NULL
* check map->phys_map[dest_id] is not NULL
* make kvm_sched_yield static
* change dest_id to unsinged long
Wanpeng Li (3):
KVM: X86: Implement PV sched yield in linux guest
KVM: X86: Implem
From: Wanpeng Li
Expose PV_SCHED_YIELD feature bit to guest, the guest can check this
feature bit before using paravirtualized sched yield.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
Documentation/virtual/kvm/cpuid.txt | 4
arch/x86/kvm/cpuid.c| 3
From: Wanpeng Li
When sending a call-function IPI-many to vCPUs, yield if any of
the IPI target vCPUs was preempted, we just select the first
preempted target vCPU which we found since the state of target
vCPUs can change underneath and to avoid race conditions.
Cc: Paolo Bonzini
Cc: Radim
301 - 400 of 5240 matches
Mail list logo
