Re: Re: [PATCH 0/2] KVM: arm/arm64: Fixes for scheudling htimer of emulated timers

On 17.02.2020 19:00, Marc Zyngier wrote: -- On 2020-02-17 14:54, Tomasz Nowicki wrote: This small series contains two fixes which were found while testing Marc's ARM NV patch set, where we are going to have at most 4 timers

[PATCH 2/2] KVM: arm/arm64: Fix htimer setup for emulated timer when irq goes down

We still need to schedule software timer if the line goes down (should_fire == 0 && should_fire != ctx->irq.level) and there is still some time to expire again. Fixes: bee038a674875 ("KVM: arm/arm64: Rework the timer code to use a timer_map") Signed-off-by: Tomasz Nowic

[PATCH 0/2] KVM: arm/arm64: Fixes for scheudling htimer of emulated timers

interrupt storm when guest enables interrupts. Second patch makes sure that hrtimer is scheduled when timer irq line goes down and there is still some time to expire. Tomasz Nowicki (2): KVM: arm/arm64: Fix spurious htimer setup for emulated timer KVM: arm/arm64: Fix htimer setup for emulated timer

[PATCH 1/2] KVM: arm/arm64: Fix spurious htimer setup for emulated timer

imer code to use a timer_map") Signed-off-by: Tomasz Nowicki --- virt/kvm/arm/arch_timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c index 0d9438e9de2a..f1814f733ef8 100644 --- a/virt/kvm/arm/arch_timer.c +++ b/virt

Re: [PATCH v9 00/11] SMMUv3 Nested Stage Setup (VFIO part)

gt; > Eric > > This series can be found at: > https://github.com/eauger/linux/tree/v5.3.0-rc0-2stage-v9 I think you have already tested on ThunderX2, but as a formality, for the whole series: Tested-by: Tomasz Nowicki qemu: https://github.com/eauger/qemu/tree/v4.1.0-rc0-2stage-rfcv5 kern

Re: [PATCH 43/59] KVM: arm64: nv: Trap and emulate AT instructions from virtual EL2

On 24.07.2019 14:39, Marc Zyngier wrote: On 24/07/2019 11:25, Tomasz Nowicki wrote: On 21.06.2019 11:38, Marc Zyngier wrote: From: Jintack Lim When supporting nested virtualization a guest hypervisor executing AT instructions must be trapped and emulated by the host hypervisor, because

Re: [PATCH 43/59] KVM: arm64: nv: Trap and emulate AT instructions from virtual EL2

On 21.06.2019 11:38, Marc Zyngier wrote: From: Jintack Lim When supporting nested virtualization a guest hypervisor executing AT instructions must be trapped and emulated by the host hypervisor, because untrapped AT instructions operating on S1E1 will use the wrong translation regieme (the one

Re: [PATCH 43/59] KVM: arm64: nv: Trap and emulate AT instructions from virtual EL2

On 18.07.2019 14:36, Alexandru Elisei wrote: On 7/18/19 1:13 PM, Tomasz Nowicki wrote: Hello Alex, On 09.07.2019 15:20, Alexandru Elisei wrote: On 6/21/19 10:38 AM, Marc Zyngier wrote: From: Jintack Lim When supporting nested virtualization a guest hypervisor executing AT instructions must

Re: [PATCH 43/59] KVM: arm64: nv: Trap and emulate AT instructions from virtual EL2

Hello Alex, On 09.07.2019 15:20, Alexandru Elisei wrote: On 6/21/19 10:38 AM, Marc Zyngier wrote: From: Jintack Lim When supporting nested virtualization a guest hypervisor executing AT instructions must be trapped and emulated by the host hypervisor, because untrapped AT instructions

Re: [PATCH v7 0/7] Add virtio-iommu driver

ons(-) > create mode 100644 Documentation/devicetree/bindings/virtio/iommu.txt > create mode 100644 drivers/iommu/virtio-iommu.c > create mode 100644 include/uapi/linux/virtio_iommu.h > I have tested the whole series and Eric's QEMU patchset [4]

Re: [PATCH 1/4] iommu: Add virtio-iommu driver

Hi Jean, On 14.02.2018 15:53, Jean-Philippe Brucker wrote: The virtio IOMMU is a para-virtualized device, allowing to send IOMMU requests such as map/unmap over virtio-mmio transport without emulating page tables. This implementation handles ATTACH, DETACH, MAP and UNMAP requests. The bulk of

Re: [PATCH v3 41/41] KVM: arm/arm64: Avoid VGICv3 save/restore on VHE with no IRQs

e function set for nvhe and vhe cases but this means massive code duplication... So I think we need to live with that, performance is top priority. For the whole series: Reviewed-by: Tomasz Nowicki <tomasz.nowi...@caviumnetworks.com> Thanks, Tomasz ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 00/41] Optimize KVM/ARM for VHE systems

On 01.02.2018 14:57, Tomasz Nowicki wrote: Hi Christoffer, I created simple module for VM kernel. It is spinning on PSCI version hypercall to measure the base exit cost as you suggested. Also, I measured CPU cycles for each loop and here are my results: My setup: 1-socket ThunderX2 running

Re: [PATCH v3 00/41] Optimize KVM/ARM for VHE systems

On 01.02.2018 17:15, Yury Norov wrote: On Thu, Feb 01, 2018 at 02:57:59PM +0100, Tomasz Nowicki wrote: Hi Christoffer, I created simple module for VM kernel. It is spinning on PSCI version hypercall to measure the base exit cost as you suggested. Also, I measured CPU cycles for each loop

Re: [PATCH v3 00/41] Optimize KVM/ARM for VHE systems

Hi Christoffer, I created simple module for VM kernel. It is spinning on PSCI version hypercall to measure the base exit cost as you suggested. Also, I measured CPU cycles for each loop and here are my results: My setup: 1-socket ThunderX2 running VM - 1VCPU Tested baselines: a) host kernel

Re: [PATCH v3 33/41] KVM: arm64: Configure FPSIMD traps on vcpu load/put

On 12.01.2018 13:07, Christoffer Dall wrote: There is no need to enable/disable traps to FP registers on every switch to/from the VM, because the host kernel does not use this resource without calling vcpu_put. We can therefore move things around enough that we still always write FPEXC32_EL2

Re: [PATCH v3 33/41] KVM: arm64: Configure FPSIMD traps on vcpu load/put

Hi Christoffer, On 12.01.2018 13:07, Christoffer Dall wrote: There is no need to enable/disable traps to FP registers on every switch to/from the VM, because the host kernel does not use this resource without calling vcpu_put. We can therefore move things around enough that we still always

Re: [PATCH v9 7/9] KVM: arm/arm64: Provide a get_input_level for the arch timer

Hi Christoffer, On 30.01.2018 13:49, Christoffer Dall wrote: Hi Tomasz, On Mon, Jan 22, 2018 at 01:32:57PM +0100, Tomasz Nowicki wrote: On 20.12.2017 12:36, Christoffer Dall wrote: The VGIC can now support the life-cycle of mapped level-triggered interrupts, and we no longer have to read

Re: [PATCH v9 7/9] KVM: arm/arm64: Provide a get_input_level for the arch timer

Hi Christoffer, On 30.01.2018 13:49, Christoffer Dall wrote: Hi Tomasz, On Mon, Jan 22, 2018 at 01:32:57PM +0100, Tomasz Nowicki wrote: On 20.12.2017 12:36, Christoffer Dall wrote: The VGIC can now support the life-cycle of mapped level-triggered interrupts, and we no longer have to read

Re: [PATCH 1/3] KVM: arm/arm64: Fix incorrect timer_is_pending logic

Hi Christoffer, I confirm the patch fixes the issue I saw before. I do not see unnecessary WFI trap storm any more, hence: Tested-by: Tomasz Nowicki <t...@semihalf.com> Thank you for fixing this. Tomasz On 30.01.2018 13:42, Christoffer Dall wrote: After the recently introduced s

Re: [PATCH v3 00/41] Optimize KVM/ARM for VHE systems

Hi Yury, On 15.01.2018 15:14, Yury Norov wrote: Hi Christoffer, [CC Sunil Goutham ] On Fri, Jan 12, 2018 at 01:07:06PM +0100, Christoffer Dall wrote: This series redesigns parts of KVM/ARM to optimize the performance on VHE systems. The general approach is to try

Re: [PATCH v9 7/9] KVM: arm/arm64: Provide a get_input_level for the arch timer

Hello Christoffer, Please see my observations/comments below. On 20.12.2017 12:36, Christoffer Dall wrote: The VGIC can now support the life-cycle of mapped level-triggered interrupts, and we no longer have to read back the timer state on every exit from the VM if we had an asserted timer

Re: [PATCH] KVM: arm/arm64: Handle forward time correction gracefully

On 11.04.2016 14:09, Tomasz Nowicki wrote: On 06.04.2016 10:37, Marc Zyngier wrote: On a host that runs NTP, corrections can have a direct impact on the background timer that we program on the behalf of a vcpu. In particular, NTP performing a forward correction will result in a timer expiring

Re: [PATCH] KVM: arm/arm64: Handle forward time correction gracefully

timecounter->mask, ->frac); - timer_arm(timer, ns); + timer_arm(timer, kvm_timer_compute_delta(vcpu)); } void kvm_timer_unschedule(struct kvm_vcpu *vcpu) Works for me, thanks Marc! Tested-by: Tomasz Nowicki <t...@semihalf.