Re: [PATCH 2/9] arm/arm64: KVM: arch_timer: Only schedule soft timer on vcpu_block

On Thu, Sep 03, 2015 at 03:43:19PM +0100, Marc Zyngier wrote: > On 30/08/15 14:54, Christoffer Dall wrote: > > We currently schedule a soft timer every time we exit the guest if the > > timer did not expire while running the guest. This is really not > > necessary, because the only work we do in

[KVMTOOL][PATCHv2] Handle KVM_EXIT_SYSTEM_EVENT on any VCPU

When VCPU #0 exits (e.g. due to KVM_EXIT_SYSTEM_EVENT), it sends SIGKVMEXIT to all other VCPUs, waits for them to exit, then tears down any remaining context. The signalling of SIGKVMEXIT is critical to forcing VCPUs to shut down in response to a system event (e.g. PSCI SYSTEM_OFF). VCPUs other

Re: [PATCH 4/9] arm/arm64: Implement GICD_ICFGR as RO for PPIs

On 30/08/15 14:54, Christoffer Dall wrote: > The GICD_ICFGR allows the bits for the SGIs and PPIs to be read only. > We currently simulate this behavior by writing a hardcoded value to the > register for the SGIs and PPIs on every write of these bits to the > register (ignoring what the guest

Re: [PATCH 1/9] KVM: Add kvm_arch_vcpu_{un}blocking callbacks

On 30/08/15 14:54, Christoffer Dall wrote: > Some times it is useful for architecture implementations of KVM to know > when the VCPU thread is about to block or when it comes back from > blocking (arm/arm64 needs to know this to properly implement timers, for > example). > > Therefore provide a

Re: [PATCH 5/9] arm/arm64: KVM: Use appropriate define in VGIC reset code

On 30/08/15 14:54, Christoffer Dall wrote: > We currently initialize the SGIs to be enabled in the VGIC code, but we > use the VGIC_NR_PPIS define for this purpose, instead of the the more > natural VGIC_NR_SGIS. Change this slightly confusing use of the > defines. > > Note: This should have no

Re: [PATCH v2 2/5] KVM: arm64: Implement vGICv3 distributor and redistributor access from userspace

On 2 September 2015 at 09:09, Pavel Fedin wrote: > The access is done similar to vGICv2, using KVM_DEV_ARM_VGIC_GRP_DIST_REGS > and KVM_DEV_ARM_VGIC_GRP_REDIST_REGS with KVM_SET_DEVICE_ATTR and > KVM_GET_DEVICE_ATTR ioctls. > > Some registers are 64-bit wide according to the

Re: [PATCH 3/9] arm/arm64: KVM: vgic: Factor out level irq processing on guest exit

On 30/08/15 14:54, Christoffer Dall wrote: > Currently vgic_process_maintenance() processes dealing with a completed > level-triggered interrupt directly, but we are soon going to reuse this > logic for level-triggered mapped interrupts with the HW bit set, so > move this logic into a separate

Re: [PATCH 6/9] arm/arm64: KVM: Add mapped interrupts documentation

On 30/08/15 14:54, Christoffer Dall wrote: > Mapped interrupts on arm/arm64 is a tricky concept and the way we deal > with them is not apparently easy to understand by reading various specs. > > Therefore, add a proper documentation file explaining the flow and > rationale of the behavior of the

Re: [PATCH 7/9] arm/arm64: KVM: vgic: Move active state handling to flush_hwstate

On 30/08/15 14:54, Christoffer Dall wrote: > We currently set the physical active state only when we *inject* a new > pending virtual interrupt, but this is actually not correct, because we > could have been preempted and run something else on the system that > resets the active state to clear.

Re: [PATCH 2/9] arm/arm64: KVM: arch_timer: Only schedule soft timer on vcpu_block

On 30/08/15 14:54, Christoffer Dall wrote: > We currently schedule a soft timer every time we exit the guest if the > timer did not expire while running the guest. This is really not > necessary, because the only work we do in the timer work function is to > kick the vcpu. > > Kicking the vcpu

Re: [PATCH 6/9] arm/arm64: KVM: Add mapped interrupts documentation

Hi Christoffer, On 09/03/2015 05:23 PM, Marc Zyngier wrote: > On 30/08/15 14:54, Christoffer Dall wrote: >> Mapped interrupts on arm/arm64 is a tricky concept and the way we deal >> with them is not apparently easy to understand by reading various specs. >> >> Therefore, add a proper documentation

Re: [PATCH 2/9] arm/arm64: KVM: arch_timer: Only schedule soft timer on vcpu_block

On Thu, Sep 03, 2015 at 04:53:22PM +0100, Marc Zyngier wrote: > On 03/09/15 15:58, Christoffer Dall wrote: > > On Thu, Sep 03, 2015 at 03:43:19PM +0100, Marc Zyngier wrote: > >> On 30/08/15 14:54, Christoffer Dall wrote: > >>> We currently schedule a soft timer every time we exit the guest if the

Re: [PATCH v6 2/3] KVM: dynamic halt_poll_ns adjustment

On Thu, Sep 3, 2015 at 2:23 AM, Wanpeng Li wrote: > > How about something like: > > @@ -1941,10 +1976,14 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) > */ > if (kvm_vcpu_check_block(vcpu) < 0) { >

Re: [PATCH 9/9] arm/arm64: KVM: arch timer: Reset CNTV_CTL to 0

On 30/08/15 14:54, Christoffer Dall wrote: > Provide a better quality of implementation and be architecture compliant > on ARMv7 for the architected timer by resetting the CNTV_CTL to 0 on > reset of the timer, and call kvm_timer_update_state(vcpu) at the same > time, ensuring the timer output is

Re: [PATCH 2/2] arm/arm64: KVM: Improve kvm_exit tracepoint

Hi Christoffer, On 30/08/15 14:55, Christoffer Dall wrote: > The ARM architecture only saves the exit class to the HSR (ESR_EL2 for > arm64) on synchronous exceptions, not on asynchronous exceptions like an > IRQ. However, we only report the exception class on kvm_exit, which is > confusing

Re: [PATCH 0/9] Rework architected timer and fix UEFI reset

Hi Christoffer, On 30/08/15 14:54, Christoffer Dall wrote: > The architected timer integration with the vgic had some shortcomings in > that certain guests (one being UEFI) weren't fully supported. > > In fixing this I also found that we are scheduling the hrtimer for the > virtual timer way too

Re: [PATCH 2/9] arm/arm64: KVM: arch_timer: Only schedule soft timer on vcpu_block

On 03/09/15 15:58, Christoffer Dall wrote: > On Thu, Sep 03, 2015 at 03:43:19PM +0100, Marc Zyngier wrote: >> On 30/08/15 14:54, Christoffer Dall wrote: >>> We currently schedule a soft timer every time we exit the guest if the >>> timer did not expire while running the guest. This is really not

Re: [PATCH 8/9] arm/arm64: KVM: Rework the arch timer to use level-triggered semantics

On 30/08/15 14:54, Christoffer Dall wrote: > The arch timer currently uses edge-triggered semantics in the sense that > the line is never sampled by the vgic and lowering the line from the > timer to the vgic doesn't have any affect on the pending state of > virtual interrupts in the vgic. This

Re: [PATCH 2/2] arm/arm64: KVM: Improve kvm_exit tracepoint

On Thu, Sep 03, 2015 at 05:29:50PM +0100, Andre Przywara wrote: > Hi Christoffer, > > On 30/08/15 14:55, Christoffer Dall wrote: > > The ARM architecture only saves the exit class to the HSR (ESR_EL2 for > > arm64) on synchronous exceptions, not on asynchronous exceptions like an > > IRQ.

Re: [PATCH 8/9] arm/arm64: KVM: Rework the arch timer to use level-triggered semantics

On Thu, Sep 03, 2015 at 06:06:39PM +0100, Marc Zyngier wrote: > On 30/08/15 14:54, Christoffer Dall wrote: > > The arch timer currently uses edge-triggered semantics in the sense that > > the line is never sampled by the vgic and lowering the line from the > > timer to the vgic doesn't have any

Re: [PATCH 8/9] arm/arm64: KVM: Rework the arch timer to use level-triggered semantics

On 03/09/15 18:23, Christoffer Dall wrote: > On Thu, Sep 03, 2015 at 06:06:39PM +0100, Marc Zyngier wrote: >> On 30/08/15 14:54, Christoffer Dall wrote: >>> The arch timer currently uses edge-triggered semantics in the sense that >>> the line is never sampled by the vgic and lowering the line from

Re: [PATCH 8/9] arm/arm64: KVM: Rework the arch timer to use level-triggered semantics

On Thu, Sep 03, 2015 at 06:29:14PM +0100, Marc Zyngier wrote: > On 03/09/15 18:23, Christoffer Dall wrote: > > On Thu, Sep 03, 2015 at 06:06:39PM +0100, Marc Zyngier wrote: > >> On 30/08/15 14:54, Christoffer Dall wrote: > >>> The arch timer currently uses edge-triggered semantics in the sense

Re: [PATCH 1/2] KVM: x86: set TMR when the interrupt is accepted

On 03/09/2015 07:18, Nakajima, Jun wrote: > On Wed, Sep 2, 2015 at 3:38 PM, Steve Rutherford > wrote: >> On Thu, Aug 13, 2015 at 09:31:48AM +0200, Paolo Bonzini wrote: >> Pinging this thread. >> >> Should I put together a patch to make split irqchip work properly with

[PATCH] KVM: PPC: fix typo in top comment about locking

Signed-off-by: Greg Kurz --- arch/powerpc/kvm/book3s_xics.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kvm/book3s_xics.c b/arch/powerpc/kvm/book3s_xics.c index c6ca7db64673..905e94a1370f 100644 ---

Re: [PATCH v6 2/3] KVM: dynamic halt_poll_ns adjustment

On 9/3/15 2:09 AM, David Matlack wrote: [...] + static int kvm_vcpu_check_block(struct kvm_vcpu *vcpu) { if (kvm_arch_vcpu_runnable(vcpu)) { @@ -1929,6 +1963,7 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) ktime_t start, cur; DEFINE_WAIT(wait); bool waited

[PATCH] KVM: PPC: fix typo in top comment about locking

Signed-off-by: Greg Kurz --- arch/powerpc/kvm/book3s_xics.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kvm/book3s_xics.c b/arch/powerpc/kvm/book3s_xics.c index c6ca7db64673..905e94a1370f 100644 ---

Re: [PATCH v6 2/3] KVM: dynamic halt_poll_ns adjustment

On 9/3/15 3:31 PM, Paolo Bonzini wrote: On 02/09/2015 21:23, David Matlack wrote: I actually wasn't thinking about vcpu->halt_poll_ns though. If single_task_running() breaks us out of the loop we will "goto out" instead of scheduling. My suspicion is this will cause us to loop calling

Re: [PATCH v6 2/3] KVM: dynamic halt_poll_ns adjustment

On 02/09/2015 21:23, David Matlack wrote: > > I actually wasn't thinking about vcpu->halt_poll_ns though. If > single_task_running() breaks us out of the loop we will "goto out" instead > of scheduling. My suspicion is this will cause us to loop calling > kvm_vcpu_block and starve the waiting

Re: [KVMTOOL][PATCH] Handle KVM_EXIT_SYSTEM_EVENT on any VCPU

On Thu, Sep 03, 2015 at 11:24:29AM +0100, Suzuki Poulose wrote: > On Wed, Sep 2, 2015 at 11:50 AM, Mark Rutland wrote: > > > > When VCPU #0 exits (e.g. due to KVM_EXIT_SYSTEM_EVENT), it sends > > SIGKVMEXIT to all other VCPUs, waits for them to exit, then tears down > > any

Re: [KVMTOOL][PATCH] Handle KVM_EXIT_SYSTEM_EVENT on any VCPU

On Wed, Sep 2, 2015 at 11:50 AM, Mark Rutland wrote: > > When VCPU #0 exits (e.g. due to KVM_EXIT_SYSTEM_EVENT), it sends > SIGKVMEXIT to all other VCPUs, waits for them to exit, then tears down > any remaining context. The signalling of SIGKVMEXIT is critical to > forcing

[PATCH] kvmtool Makefile: relax arm test

From: Riku Voipio Currently Makefile accepts only armv7l.* When building kvmtool under 32bit personality on Aarch64 machines, uname -m reports "armv8l", so build fails. We expect doing 32bit arm builds in Aarch64 to become standard the same way people do i386 builds on

Re: [PATCH v6 2/3] KVM: dynamic halt_poll_ns adjustment

On 9/4/15 12:07 AM, David Matlack wrote: On Thu, Sep 3, 2015 at 2:23 AM, Wanpeng Li wrote: How about something like: @@ -1941,10 +1976,14 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) */ if (kvm_vcpu_check_block(vcpu)

Please add my kvm-ppc-next branch to linux-next

Hi Stephen, Please include the kvm-ppc-next branch of my powerpc git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git to linux-next. This branch currently only has commits that are intended to go into 4.3, and I won't put in any commits for 4.4 until 4.3-rc1 is out.

[PATCH v7 2/3] KVM: dynamic halt-polling

There is a downside of always-poll since poll is still happened for idle vCPUs which can waste cpu usage. This patchset add the ability to adjust halt_poll_ns dynamically, to grow halt_poll_ns when shot halt is detected, and to shrink halt_poll_ns when long halt is detected. There are two new

[PATCH v7 0/3] KVM: Dynamic Halt-Polling

v6 -> v7: * explicit signal (set a bool) * fix the tracepoint v5 -> v6: * fix wait_ns and poll_ns v4 -> v5: * set base case 10us and max poll time 500us * handle short/long halt, idea from David, many thanks David v3 -> v4: * bring back grow vcpu->halt_poll_ns when interrupt arrives

[PATCH v7 1/3] KVM: make halt_poll_ns per-vCPU

Change halt_poll_ns into per-VCPU variable, seeded from module parameter, to allow greater flexibility. Signed-off-by: Wanpeng Li --- include/linux/kvm_host.h | 1 + virt/kvm/kvm_main.c | 5 +++-- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git

[PATCH v7 3/3] KVM: trace kvm_halt_poll_ns grow/shrink

Tracepoint for dynamic halt_pool_ns, fired on every potential change. Signed-off-by: Wanpeng Li --- include/trace/events/kvm.h | 30 ++ virt/kvm/kvm_main.c| 8 ++-- 2 files changed, 36 insertions(+), 2 deletions(-) diff --git

Re: [PATCH v6 2/3] KVM: dynamic halt_poll_ns adjustment

On 9/3/15 2:09 AM, David Matlack wrote: On Wed, Sep 2, 2015 at 12:29 AM, Wanpeng Li wrote: There is a downside of always-poll since poll is still happened for idle vCPUs which can waste cpu usage. This patch adds the ability to adjust halt_poll_ns dynamically, to grow

Re: [PATCH v6 2/3] KVM: dynamic halt_poll_ns adjustment

On 9/4/15 9:16 AM, Wanpeng Li wrote: [...] + static int kvm_vcpu_check_block(struct kvm_vcpu *vcpu) { if (kvm_arch_vcpu_runnable(vcpu)) { @@ -1929,6 +1963,7 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) ktime_t start, cur; DEFINE_WAIT(wait); bool waited =