linux.git/arch/powerpc/kvm, branch v3.12.65

KVM: PPC: Book3s PR: Allow access to unprivileged MMCR2 register

2016-10-17T07:46:19+00:00

commit fa73c3b25bd8d0d393dc6109a1dba3c2aef0451e upstream.

The MMCR2 register is available twice, one time with number 785
(privileged access), and one time with number 769 (unprivileged,
but it can be disabled completely). In former times, the Linux
kernel was using the unprivileged register 769 only, but since
commit 8dd75ccb571f3c92c ("powerpc: Use privileged SPR number
for MMCR2"), it uses the privileged register 785 instead.
The KVM-PR code then of course also switched to use the SPR 785,
but this is causing older guest kernels to crash, since these
kernels still access 769 instead. So to support older kernels
with KVM-PR again, we have to support register 769 in KVM-PR, too.

Fixes: 8dd75ccb571f3c92c48014b3dabd3d51a115ab41
Signed-off-by: Thomas Huth 
Signed-off-by: Paul Mackerras 
Signed-off-by: Jiri Slaby

KVM: PPC: Book3S PR: Emulate TIR register

2016-10-17T07:35:09+00:00

commit a5948fa092a04dfd6b9ee31c99eb6896c158eb08 upstream.

In parallel to the Processor ID Register (PIR) threaded POWER8 also adds a
Thread ID Register (TIR). Since PR KVM doesn't emulate more than one thread
per core, we can just always expose 0 here.

Signed-off-by: Alexander Graf 
Signed-off-by: Jiri Slaby

KVM: PPC: Book3S PR: Ignore PMU SPRs

2016-10-17T07:34:18+00:00

commit f8f6eb0d189cf2724af5ebc8cad460c78fb1994e upstream.

When we expose a POWER8 CPU into the guest, it will start accessing PMU SPRs
that we don't emulate. Just ignore accesses to them.

Signed-off-by: Alexander Graf 
Signed-off-by: Jiri Slaby

KVM: PPC: Book3S HV: Prohibit setting illegal transaction state in MSR

2016-01-25T14:15:40+00:00

commit c20875a3e638e4a03e099b343ec798edd1af5cc6 upstream.

Currently it is possible for userspace (e.g. QEMU) to set a value
for the MSR for a guest VCPU which has both of the TS bits set,
which is an illegal combination.  The result of this is that when
we execute a hrfid (hypervisor return from interrupt doubleword)
instruction to enter the guest, the CPU will take a TM Bad Thing
type of program interrupt (vector 0x700).

Now, if PR KVM is configured in the kernel along with HV KVM, we
actually handle this without crashing the host or giving hypervisor
privilege to the guest; instead what happens is that we deliver a
program interrupt to the guest, with SRR0 reflecting the address
of the hrfid instruction and SRR1 containing the MSR value at that
point.  If PR KVM is not configured in the kernel, then we try to
run the host's program interrupt handler with the MMU set to the
guest context, which almost certainly causes a host crash.

This closes the hole by making kvmppc_set_msr_hv() check for the
illegal combination and force the TS field to a safe value (00,
meaning non-transactional).

Signed-off-by: Paul Mackerras 
Signed-off-by: Jiri Slaby

KVM: PPC: Book3S HV: Fix KVM hang with CONFIG_KVM_XICS=n

2014-07-02T10:05:55+00:00

commit 7505258c5fcb0a1cc3c76a47b4cf9506d21d10e6 upstream.

I noticed KVM is broken when KVM in-kernel XICS emulation
(CONFIG_KVM_XICS) is disabled.

The problem was introduced in 48eaef05 (KVM: PPC: Book3S HV: use
xics_wake_cpu only when defined). It used CONFIG_KVM_XICS to wrap
xics_wake_cpu, where CONFIG_PPC_ICP_NATIVE should have been
used.

Signed-off-by: Anton Blanchard 
Cc: stable@vger.kernel.org
Signed-off-by: Paul Mackerras 
Acked-by: Scott Wood 
Signed-off-by: Jiri Slaby

KVM: PPC: e500: Fix bad address type in deliver_tlb_misss()

2014-02-06T19:22:21+00:00

commit 70713fe315ed14cd1bb07d1a7f33e973d136ae3d upstream.

Use gva_t instead of unsigned int for eaddr in deliver_tlb_miss().

Signed-off-by: Mihai Caraman 
Signed-off-by: Alexander Graf 
Signed-off-by: Greg Kroah-Hartman

KVM: PPC: Book3S HV: use xics_wake_cpu only when defined

2014-02-06T19:22:21+00:00

commit 48eaef0518a565d3852e301c860e1af6a6db5a84 upstream.

Signed-off-by: Andreas Schwab 
Signed-off-by: Alexander Graf 
Signed-off-by: Greg Kroah-Hartman

powerpc: kvm: fix rare but potential deadlock scene

2014-01-09T20:25:07+00:00

commit 91648ec09c1ef69c4d840ab6dab391bfb452d554 upstream.

Since kvmppc_hv_find_lock_hpte() is called from both virtmode and
realmode, so it can trigger the deadlock.

Suppose the following scene:

Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of
vcpus.

If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is switched
out, and on cpuN, vcpu_A_2 try to lock X in realmode, then cpuN will be
caught in realmode for a long time.

What makes things even worse if the following happens,
  On cpuM, bitlockX is hold, on cpuN, Y is hold.
  vcpu_B_2 try to lock Y on cpuM in realmode
  vcpu_A_2 try to lock X on cpuN in realmode

Oops! deadlock happens

Signed-off-by: Liu Ping Fan 
Reviewed-by: Paul Mackerras 
Signed-off-by: Alexander Graf 
Signed-off-by: Greg Kroah-Hartman

kvm: ppc: booke: check range page invalidation progress on page setup

2013-10-10T09:40:08+00:00

When the MM code is invalidating a range of pages, it calls the KVM
kvm_mmu_notifier_invalidate_range_start() notifier function, which calls
kvm_unmap_hva_range(), which arranges to flush all the TLBs for guest pages.
However, the Linux PTEs for the range being flushed are still valid at
that point.  We are not supposed to establish any new references to pages
in the range until the ...range_end() notifier gets called.
The PPC-specific KVM code doesn't get any explicit notification of that;
instead, we are supposed to use mmu_notifier_retry() to test whether we
are or have been inside a range flush notifier pair while we have been
referencing a page.

This patch calls the mmu_notifier_retry() while mapping the guest
page to ensure we are not referencing a page when in range invalidation.

This call is inside a region locked with kvm->mmu_lock, which is the
same lock that is called by the KVM MMU notifier functions, thus
ensuring that no new notification can proceed while we are in the
locked region.

Signed-off-by: Bharat Bhushan 
Acked-by: Alexander Graf 
[Backported to 3.12 - Paolo]
Reviewed-by: Bharat Bhushan 
Signed-off-by: Paolo Bonzini

KVM: PPC: Book3S HV: Fix typo in saving DSCR

2013-10-10T09:40:07+00:00

This fixes a typo in the code that saves the guest DSCR (Data Stream
Control Register) into the kvm_vcpu_arch struct on guest exit.  The
effect of the typo was that the DSCR value was saved in the wrong place,
so changes to the DSCR by the guest didn't persist across guest exit
and entry, and some host kernel memory got corrupted.

Cc: stable@vger.kernel.org [v3.1+]
Signed-off-by: Paul Mackerras 
Acked-by: Alexander Graf 
Signed-off-by: Paolo Bonzini