When running kvm_vcpu_block and it realizes that the CPU is actually good
to run, we get a request bit set for KVM_REQ_UNHALT. Right now, there's
nothing we can do with that bit, so let's unset it right after the call
again so we don't get confused in our later checks for pending work.
Signed-off-
We were leaking preemption counters. Fix the code to always toggle
between preempt and non-preempt properly.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_pr.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/b
When running PR KVM on a p7 system in bare metal, we get HV exits instead
of normal supervisor traps. Semantically they are identical though and the
HSRR vs SRR difference is already taken care of in the exit code.
So all we need to do is handle them in addition to our normal exits.
Signed-off-by
On 14.03.2012, at 08:52, Benjamin Herrenschmidt wrote:
> When the kernel calls into RTAS, it switches to 32-bit mode. The
> magic page was is longer accessible in that case, causing the
> patched instructions in the RTAS call wrapper to crash.
>
> This fixes it by making available a 32-bit mappi
Hi Alex !
Saw that in my log today:
=
BUG kvm-spt (Not tainted): Objects remaining on kmem_cache_close()
-
INFO: Slab 0xc5a82470 objects
On Wed, 2012-03-14 at 18:52 +1100, Benjamin Herrenschmidt wrote:
> When the kernel calls into RTAS, it switches to 32-bit mode. The
> magic page was is longer accessible in that case, causing the
> patched instructions in the RTAS call wrapper to crash.
>
> This fixes it by making available a 32-b
When the kernel calls into RTAS, it switches to 32-bit mode. The
magic page was is longer accessible in that case, causing the
patched instructions in the RTAS call wrapper to crash.
This fixes it by making available a 32-bit mapping of the magic
page in that case. This mapping is flushed whenever
