| 05e0127f9e362b36aa35f17b1a3d52bca9322a3a |
|
26-Aug-2014 |
Christoffer Dall <christoffer.dall@linaro.org> |
arm/arm64: KVM: Complete WFI/WFE instructions
The architecture specifies that when the processor wakes up from a WFE
or WFI instruction, the instruction is considered complete, however we
currrently return to EL1 (or EL0) at the WFI/WFE instruction itself.
While most guests may not be affected by this because their local
exception handler performs an exception returning setting the event bit
or with an interrupt pending, some guests like UEFI will get wedged due
this little mishap.
Simply skip the instruction when we have completed the emulation.
Cc: <stable@vger.kernel.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
|
| e8e7fcc5e2710b31ef842ee799db99c07986c364 |
|
29-Apr-2014 |
Anup Patel <anup.patel@linaro.org> |
ARM/ARM64: KVM: Make kvm_psci_call() return convention more flexible
Currently, the kvm_psci_call() returns 'true' or 'false' based on whether
the PSCI function call was handled successfully or not. This does not help
us emulate system-level PSCI functions where the actual emulation work will
be done by user space (QEMU or KVMTOOL). Examples of such system-level PSCI
functions are: PSCI v0.2 SYSTEM_OFF and SYSTEM_RESET.
This patch updates kvm_psci_call() to return three types of values:
1) > 0 (success)
2) = 0 (success but exit to user space)
3) < 0 (errors)
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
|
| 61466710de078c697106fa5b70ec7afc9feab520 |
|
07-Jan-2014 |
Sachin Kamat <sachin.kamat@linaro.org> |
KVM: ARM: Remove duplicate include
trace.h was included twice. Remove duplicate inclusion.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
|
| 86ed81aa2e1ce05a4e7f0819f0dfc34e8d8fb910 |
|
16-Oct-2013 |
Christoffer Dall <christoffer.dall@linaro.org> |
KVM: ARM: Update comments for kvm_handle_wfi
Update comments to reflect what is really going on and add the TWE bit
to the comments in kvm_arm.h.
Also renames the function to kvm_handle_wfx like is done on arm64 for
consistency and uber-correctness.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
|
| 58d5ec8f8ee318b26b29207874fbaee626973952 |
|
08-Oct-2013 |
Marc Zyngier <marc.zyngier@arm.com> |
ARM: KVM: Yield CPU when vcpu executes a WFE
On an (even slightly) oversubscribed system, spinlocks are quickly
becoming a bottleneck, as some vcpus are spinning, waiting for a
lock to be released, while the vcpu holding the lock may not be
running at all.
This creates contention, and the observed slowdown is 40x for
hackbench. No, this isn't a typo.
The solution is to trap blocking WFEs and tell KVM that we're
now spinning. This ensures that other vpus will get a scheduling
boost, allowing the lock to be released more quickly. Also, using
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT slightly improves the performance
when the VM is severely overcommited.
Quick test to estimate the performance: hackbench 1 process 1000
2xA15 host (baseline): 1.843s
2xA15 guest w/o patch: 2.083s
4xA15 guest w/o patch: 80.212s
8xA15 guest w/o patch: Could not be bothered to find out
2xA15 guest w/ patch: 2.102s
4xA15 guest w/ patch: 3.205s
8xA15 guest w/ patch: 6.887s
So we go from a 40x degradation to 1.5x in the 2x overcommit case,
which is vaguely more acceptable.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
|
| 82ea046c95a3c3ddcfa058c8a270b9afb6e93700 |
|
16-Oct-2013 |
Christoffer Dall <christoffer.dall@linaro.org> |
KVM: ARM: Update comments for kvm_handle_wfi
Update comments to reflect what is really going on and add the TWE bit
to the comments in kvm_arm.h.
Also renames the function to kvm_handle_wfx like is done on arm64 for
consistency and uber-correctness.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
|
| 1f5580986a3667e9d67b65d916bb4249fd86a400 |
|
08-Oct-2013 |
Marc Zyngier <marc.zyngier@arm.com> |
ARM: KVM: Yield CPU when vcpu executes a WFE
On an (even slightly) oversubscribed system, spinlocks are quickly
becoming a bottleneck, as some vcpus are spinning, waiting for a
lock to be released, while the vcpu holding the lock may not be
running at all.
This creates contention, and the observed slowdown is 40x for
hackbench. No, this isn't a typo.
The solution is to trap blocking WFEs and tell KVM that we're
now spinning. This ensures that other vpus will get a scheduling
boost, allowing the lock to be released more quickly. Also, using
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT slightly improves the performance
when the VM is severely overcommited.
Quick test to estimate the performance: hackbench 1 process 1000
2xA15 host (baseline): 1.843s
2xA15 guest w/o patch: 2.083s
4xA15 guest w/o patch: 80.212s
8xA15 guest w/o patch: Could not be bothered to find out
2xA15 guest w/ patch: 2.102s
4xA15 guest w/ patch: 3.205s
8xA15 guest w/ patch: 6.887s
So we go from a 40x degradation to 1.5x in the 2x overcommit case,
which is vaguely more acceptable.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
|
| 24a7f675752e06729589d40a5256970998a21502 |
|
01-May-2013 |
Dave P Martin <Dave.Martin@arm.com> |
ARM: KVM: Don't handle PSCI calls via SMC
Currently, kvmtool unconditionally declares that HVC should be used
to call PSCI, so the function numbers in the DT tell the guest
nothing about the function ID namespace or calling convention for
SMC.
We already assume that the guest will examine and honour the DT,
since there is no way it could possibly guess the KVM-specific PSCI
function IDs otherwise. So let's not encourage guests to violate
what's specified in the DT by using SMC to make the call.
[ Modified to apply to top of kvm/arm tree - Christoffer ]
Signed-off-by: Dave P Martin <Dave.Martin@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
|
| df759217386fcff9c5e45547d1578270fd592a1b |
|
23-Apr-2013 |
Christoffer Dall <cdall@cs.columbia.edu> |
KVM: ARM: Fix spelling in error message
s/unkown/unknown/
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
|
| 6190920a35068a621570cca7f07f3c4477615176 |
|
05-Oct-2012 |
Marc Zyngier <marc.zyngier@arm.com> |
ARM: KVM: move kvm_handle_wfi to handle_exit.c
It has little to do in emulate.c these days...
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
| c088f8f0088decf0ce172a6bb4a6f5742cc54c15 |
|
21-Feb-2013 |
Christoffer Dall <cdall@cs.columbia.edu> |
KVM: ARM: Reintroduce trace_kvm_hvc
This one got lost in the move to handle_exit, so let's reintroduce it
using an accessor to the immediate value field like the other ones.
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
|
| 3414bbfff98b2524c0b2cdc4d0a78153ebf4f823 |
|
05-Oct-2012 |
Marc Zyngier <marc.zyngier@arm.com> |
ARM: KVM: move exit handler selection to a separate file
The exit handler selection code cannot be shared with arm64
(two different modes, more exception classes...).
Move it to a separate file (handle_exit.c).
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
|