* [PULL 0/3] 4.0 patch queue 2015-03-25
@ 2015-03-25 21:58 ` Alexander Graf
0 siblings, 0 replies; 10+ messages in thread
From: Alexander Graf @ 2015-03-25 21:58 UTC (permalink / raw)
To: kvm-ppc; +Cc: kvm, pbonzini, mtosatti
Hi Paolo,
This is my current patch queue for 4.0. Please pull.
Alex
The following changes since commit f710a12d73dfa1c3a5d2417f2482b970f03bb850:
Merge tag 'kvm-arm-fixes-4.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm (2015-03-16 20:08:56 -0300)
are available in the git repository at:
git://github.com/agraf/linux-2.6.git tags/signed-for-4.0
for you to fetch changes up to 2bf27601c7b50b6ced72f27304109dc52eb52919:
KVM: PPC: Book3S HV: Fix instruction emulation (2015-03-20 11:42:33 +0100)
----------------------------------------------------------------
Patch queue for 4.0 - 2015-03-25
A few bug fixes for Book3S HV KVM:
- Fix spinlock ordering
- Fix idle guests on LE hosts
- Fix instruction emulation
----------------------------------------------------------------
Paul Mackerras (3):
KVM: PPC: Book3S HV: Fix spinlock/mutex ordering issue in kvmppc_set_lpcr()
KVM: PPC: Book3S HV: Endian fix for accessing VPA yield count
KVM: PPC: Book3S HV: Fix instruction emulation
arch/powerpc/kvm/book3s_hv.c | 8 ++++----
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 1 +
2 files changed, 5 insertions(+), 4 deletions(-)
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PULL 0/3] 4.0 patch queue 2015-03-25
@ 2015-03-25 21:58 ` Alexander Graf
0 siblings, 0 replies; 10+ messages in thread
From: Alexander Graf @ 2015-03-25 21:58 UTC (permalink / raw)
To: kvm-ppc; +Cc: kvm, pbonzini, mtosatti
Hi Paolo,
This is my current patch queue for 4.0. Please pull.
Alex
The following changes since commit f710a12d73dfa1c3a5d2417f2482b970f03bb850:
Merge tag 'kvm-arm-fixes-4.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm (2015-03-16 20:08:56 -0300)
are available in the git repository at:
git://github.com/agraf/linux-2.6.git tags/signed-for-4.0
for you to fetch changes up to 2bf27601c7b50b6ced72f27304109dc52eb52919:
KVM: PPC: Book3S HV: Fix instruction emulation (2015-03-20 11:42:33 +0100)
----------------------------------------------------------------
Patch queue for 4.0 - 2015-03-25
A few bug fixes for Book3S HV KVM:
- Fix spinlock ordering
- Fix idle guests on LE hosts
- Fix instruction emulation
----------------------------------------------------------------
Paul Mackerras (3):
KVM: PPC: Book3S HV: Fix spinlock/mutex ordering issue in kvmppc_set_lpcr()
KVM: PPC: Book3S HV: Endian fix for accessing VPA yield count
KVM: PPC: Book3S HV: Fix instruction emulation
arch/powerpc/kvm/book3s_hv.c | 8 ++++----
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 1 +
2 files changed, 5 insertions(+), 4 deletions(-)
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PULL 1/3] KVM: PPC: Book3S HV: Fix spinlock/mutex ordering issue in kvmppc_set_lpcr()
2015-03-25 21:58 ` Alexander Graf
@ 2015-03-25 21:58 ` Alexander Graf
-1 siblings, 0 replies; 10+ messages in thread
From: Alexander Graf @ 2015-03-25 21:58 UTC (permalink / raw)
To: kvm-ppc; +Cc: kvm, pbonzini, mtosatti, Paul Mackerras
From: Paul Mackerras <paulus@samba.org>
Currently, kvmppc_set_lpcr() has a spinlock around the whole function,
and inside that does mutex_lock(&kvm->lock). It is not permitted to
take a mutex while holding a spinlock, because the mutex_lock might
call schedule(). In addition, this causes lockdep to warn about a
lock ordering issue:
======================================================
[ INFO: possible circular locking dependency detected ]
3.18.0-kvm-04645-gdfea862-dirty #131 Not tainted
-------------------------------------------------------
qemu-system-ppc/8179 is trying to acquire lock:
(&kvm->lock){+.+.+.}, at: [<d00000000ecc1f54>] .kvmppc_set_lpcr+0xf4/0x1c0 [kvm_hv]
but task is already holding lock:
(&(&vcore->lock)->rlock){+.+...}, at: [<d00000000ecc1ea0>] .kvmppc_set_lpcr+0x40/0x1c0 [kvm_hv]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&(&vcore->lock)->rlock){+.+...}:
[<c000000000b3c120>] .mutex_lock_nested+0x80/0x570
[<d00000000ecc7a14>] .kvmppc_vcpu_run_hv+0xc4/0xe40 [kvm_hv]
[<d00000000eb9f5cc>] .kvmppc_vcpu_run+0x2c/0x40 [kvm]
[<d00000000eb9cb24>] .kvm_arch_vcpu_ioctl_run+0x54/0x160 [kvm]
[<d00000000eb94478>] .kvm_vcpu_ioctl+0x4a8/0x7b0 [kvm]
[<c00000000026cbb4>] .do_vfs_ioctl+0x444/0x770
[<c00000000026cfa4>] .SyS_ioctl+0xc4/0xe0
[<c000000000009264>] syscall_exit+0x0/0x98
-> #0 (&kvm->lock){+.+.+.}:
[<c0000000000ff28c>] .lock_acquire+0xcc/0x1a0
[<c000000000b3c120>] .mutex_lock_nested+0x80/0x570
[<d00000000ecc1f54>] .kvmppc_set_lpcr+0xf4/0x1c0 [kvm_hv]
[<d00000000ecc510c>] .kvmppc_set_one_reg_hv+0x4dc/0x990 [kvm_hv]
[<d00000000eb9f234>] .kvmppc_set_one_reg+0x44/0x330 [kvm]
[<d00000000eb9c9dc>] .kvm_vcpu_ioctl_set_one_reg+0x5c/0x150 [kvm]
[<d00000000eb9ced4>] .kvm_arch_vcpu_ioctl+0x214/0x2c0 [kvm]
[<d00000000eb940b0>] .kvm_vcpu_ioctl+0xe0/0x7b0 [kvm]
[<c00000000026cbb4>] .do_vfs_ioctl+0x444/0x770
[<c00000000026cfa4>] .SyS_ioctl+0xc4/0xe0
[<c000000000009264>] syscall_exit+0x0/0x98
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&(&vcore->lock)->rlock);
lock(&kvm->lock);
lock(&(&vcore->lock)->rlock);
lock(&kvm->lock);
*** DEADLOCK ***
2 locks held by qemu-system-ppc/8179:
#0: (&vcpu->mutex){+.+.+.}, at: [<d00000000eb93f18>] .vcpu_load+0x28/0x90 [kvm]
#1: (&(&vcore->lock)->rlock){+.+...}, at: [<d00000000ecc1ea0>] .kvmppc_set_lpcr+0x40/0x1c0 [kvm_hv]
stack backtrace:
CPU: 4 PID: 8179 Comm: qemu-system-ppc Not tainted 3.18.0-kvm-04645-gdfea862-dirty #131
Call Trace:
[c000001a66c0f310] [c000000000b486ac] .dump_stack+0x88/0xb4 (unreliable)
[c000001a66c0f390] [c0000000000f8bec] .print_circular_bug+0x27c/0x3d0
[c000001a66c0f440] [c0000000000fe9e8] .__lock_acquire+0x2028/0x2190
[c000001a66c0f5d0] [c0000000000ff28c] .lock_acquire+0xcc/0x1a0
[c000001a66c0f6a0] [c000000000b3c120] .mutex_lock_nested+0x80/0x570
[c000001a66c0f7c0] [d00000000ecc1f54] .kvmppc_set_lpcr+0xf4/0x1c0 [kvm_hv]
[c000001a66c0f860] [d00000000ecc510c] .kvmppc_set_one_reg_hv+0x4dc/0x990 [kvm_hv]
[c000001a66c0f8d0] [d00000000eb9f234] .kvmppc_set_one_reg+0x44/0x330 [kvm]
[c000001a66c0f960] [d00000000eb9c9dc] .kvm_vcpu_ioctl_set_one_reg+0x5c/0x150 [kvm]
[c000001a66c0f9f0] [d00000000eb9ced4] .kvm_arch_vcpu_ioctl+0x214/0x2c0 [kvm]
[c000001a66c0faf0] [d00000000eb940b0] .kvm_vcpu_ioctl+0xe0/0x7b0 [kvm]
[c000001a66c0fcb0] [c00000000026cbb4] .do_vfs_ioctl+0x444/0x770
[c000001a66c0fd90] [c00000000026cfa4] .SyS_ioctl+0xc4/0xe0
[c000001a66c0fe30] [c000000000009264] syscall_exit+0x0/0x98
This fixes it by moving the mutex_lock()/mutex_unlock() pair outside
the spin-locked region.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/book3s_hv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index de4018a..b273193 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -942,20 +942,20 @@ static int kvm_arch_vcpu_ioctl_set_sregs_hv(struct kvm_vcpu *vcpu,
static void kvmppc_set_lpcr(struct kvm_vcpu *vcpu, u64 new_lpcr,
bool preserve_top32)
{
+ struct kvm *kvm = vcpu->kvm;
struct kvmppc_vcore *vc = vcpu->arch.vcore;
u64 mask;
+ mutex_lock(&kvm->lock);
spin_lock(&vc->lock);
/*
* If ILE (interrupt little-endian) has changed, update the
* MSR_LE bit in the intr_msr for each vcpu in this vcore.
*/
if ((new_lpcr & LPCR_ILE) != (vc->lpcr & LPCR_ILE)) {
- struct kvm *kvm = vcpu->kvm;
struct kvm_vcpu *vcpu;
int i;
- mutex_lock(&kvm->lock);
kvm_for_each_vcpu(i, vcpu, kvm) {
if (vcpu->arch.vcore != vc)
continue;
@@ -964,7 +964,6 @@ static void kvmppc_set_lpcr(struct kvm_vcpu *vcpu, u64 new_lpcr,
else
vcpu->arch.intr_msr &= ~MSR_LE;
}
- mutex_unlock(&kvm->lock);
}
/*
@@ -981,6 +980,7 @@ static void kvmppc_set_lpcr(struct kvm_vcpu *vcpu, u64 new_lpcr,
mask &= 0xFFFFFFFF;
vc->lpcr = (vc->lpcr & ~mask) | (new_lpcr & mask);
spin_unlock(&vc->lock);
+ mutex_unlock(&kvm->lock);
}
static int kvmppc_get_one_reg_hv(struct kvm_vcpu *vcpu, u64 id,
--
1.8.1.4
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PULL 1/3] KVM: PPC: Book3S HV: Fix spinlock/mutex ordering issue in kvmppc_set_lpcr()
@ 2015-03-25 21:58 ` Alexander Graf
0 siblings, 0 replies; 10+ messages in thread
From: Alexander Graf @ 2015-03-25 21:58 UTC (permalink / raw)
To: kvm-ppc; +Cc: kvm, pbonzini, mtosatti, Paul Mackerras
From: Paul Mackerras <paulus@samba.org>
Currently, kvmppc_set_lpcr() has a spinlock around the whole function,
and inside that does mutex_lock(&kvm->lock). It is not permitted to
take a mutex while holding a spinlock, because the mutex_lock might
call schedule(). In addition, this causes lockdep to warn about a
lock ordering issue:
===========================
[ INFO: possible circular locking dependency detected ]
3.18.0-kvm-04645-gdfea862-dirty #131 Not tainted
-------------------------------------------------------
qemu-system-ppc/8179 is trying to acquire lock:
(&kvm->lock){+.+.+.}, at: [<d00000000ecc1f54>] .kvmppc_set_lpcr+0xf4/0x1c0 [kvm_hv]
but task is already holding lock:
(&(&vcore->lock)->rlock){+.+...}, at: [<d00000000ecc1ea0>] .kvmppc_set_lpcr+0x40/0x1c0 [kvm_hv]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&(&vcore->lock)->rlock){+.+...}:
[<c000000000b3c120>] .mutex_lock_nested+0x80/0x570
[<d00000000ecc7a14>] .kvmppc_vcpu_run_hv+0xc4/0xe40 [kvm_hv]
[<d00000000eb9f5cc>] .kvmppc_vcpu_run+0x2c/0x40 [kvm]
[<d00000000eb9cb24>] .kvm_arch_vcpu_ioctl_run+0x54/0x160 [kvm]
[<d00000000eb94478>] .kvm_vcpu_ioctl+0x4a8/0x7b0 [kvm]
[<c00000000026cbb4>] .do_vfs_ioctl+0x444/0x770
[<c00000000026cfa4>] .SyS_ioctl+0xc4/0xe0
[<c000000000009264>] syscall_exit+0x0/0x98
-> #0 (&kvm->lock){+.+.+.}:
[<c0000000000ff28c>] .lock_acquire+0xcc/0x1a0
[<c000000000b3c120>] .mutex_lock_nested+0x80/0x570
[<d00000000ecc1f54>] .kvmppc_set_lpcr+0xf4/0x1c0 [kvm_hv]
[<d00000000ecc510c>] .kvmppc_set_one_reg_hv+0x4dc/0x990 [kvm_hv]
[<d00000000eb9f234>] .kvmppc_set_one_reg+0x44/0x330 [kvm]
[<d00000000eb9c9dc>] .kvm_vcpu_ioctl_set_one_reg+0x5c/0x150 [kvm]
[<d00000000eb9ced4>] .kvm_arch_vcpu_ioctl+0x214/0x2c0 [kvm]
[<d00000000eb940b0>] .kvm_vcpu_ioctl+0xe0/0x7b0 [kvm]
[<c00000000026cbb4>] .do_vfs_ioctl+0x444/0x770
[<c00000000026cfa4>] .SyS_ioctl+0xc4/0xe0
[<c000000000009264>] syscall_exit+0x0/0x98
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&(&vcore->lock)->rlock);
lock(&kvm->lock);
lock(&(&vcore->lock)->rlock);
lock(&kvm->lock);
*** DEADLOCK ***
2 locks held by qemu-system-ppc/8179:
#0: (&vcpu->mutex){+.+.+.}, at: [<d00000000eb93f18>] .vcpu_load+0x28/0x90 [kvm]
#1: (&(&vcore->lock)->rlock){+.+...}, at: [<d00000000ecc1ea0>] .kvmppc_set_lpcr+0x40/0x1c0 [kvm_hv]
stack backtrace:
CPU: 4 PID: 8179 Comm: qemu-system-ppc Not tainted 3.18.0-kvm-04645-gdfea862-dirty #131
Call Trace:
[c000001a66c0f310] [c000000000b486ac] .dump_stack+0x88/0xb4 (unreliable)
[c000001a66c0f390] [c0000000000f8bec] .print_circular_bug+0x27c/0x3d0
[c000001a66c0f440] [c0000000000fe9e8] .__lock_acquire+0x2028/0x2190
[c000001a66c0f5d0] [c0000000000ff28c] .lock_acquire+0xcc/0x1a0
[c000001a66c0f6a0] [c000000000b3c120] .mutex_lock_nested+0x80/0x570
[c000001a66c0f7c0] [d00000000ecc1f54] .kvmppc_set_lpcr+0xf4/0x1c0 [kvm_hv]
[c000001a66c0f860] [d00000000ecc510c] .kvmppc_set_one_reg_hv+0x4dc/0x990 [kvm_hv]
[c000001a66c0f8d0] [d00000000eb9f234] .kvmppc_set_one_reg+0x44/0x330 [kvm]
[c000001a66c0f960] [d00000000eb9c9dc] .kvm_vcpu_ioctl_set_one_reg+0x5c/0x150 [kvm]
[c000001a66c0f9f0] [d00000000eb9ced4] .kvm_arch_vcpu_ioctl+0x214/0x2c0 [kvm]
[c000001a66c0faf0] [d00000000eb940b0] .kvm_vcpu_ioctl+0xe0/0x7b0 [kvm]
[c000001a66c0fcb0] [c00000000026cbb4] .do_vfs_ioctl+0x444/0x770
[c000001a66c0fd90] [c00000000026cfa4] .SyS_ioctl+0xc4/0xe0
[c000001a66c0fe30] [c000000000009264] syscall_exit+0x0/0x98
This fixes it by moving the mutex_lock()/mutex_unlock() pair outside
the spin-locked region.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/book3s_hv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index de4018a..b273193 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -942,20 +942,20 @@ static int kvm_arch_vcpu_ioctl_set_sregs_hv(struct kvm_vcpu *vcpu,
static void kvmppc_set_lpcr(struct kvm_vcpu *vcpu, u64 new_lpcr,
bool preserve_top32)
{
+ struct kvm *kvm = vcpu->kvm;
struct kvmppc_vcore *vc = vcpu->arch.vcore;
u64 mask;
+ mutex_lock(&kvm->lock);
spin_lock(&vc->lock);
/*
* If ILE (interrupt little-endian) has changed, update the
* MSR_LE bit in the intr_msr for each vcpu in this vcore.
*/
if ((new_lpcr & LPCR_ILE) != (vc->lpcr & LPCR_ILE)) {
- struct kvm *kvm = vcpu->kvm;
struct kvm_vcpu *vcpu;
int i;
- mutex_lock(&kvm->lock);
kvm_for_each_vcpu(i, vcpu, kvm) {
if (vcpu->arch.vcore != vc)
continue;
@@ -964,7 +964,6 @@ static void kvmppc_set_lpcr(struct kvm_vcpu *vcpu, u64 new_lpcr,
else
vcpu->arch.intr_msr &= ~MSR_LE;
}
- mutex_unlock(&kvm->lock);
}
/*
@@ -981,6 +980,7 @@ static void kvmppc_set_lpcr(struct kvm_vcpu *vcpu, u64 new_lpcr,
mask &= 0xFFFFFFFF;
vc->lpcr = (vc->lpcr & ~mask) | (new_lpcr & mask);
spin_unlock(&vc->lock);
+ mutex_unlock(&kvm->lock);
}
static int kvmppc_get_one_reg_hv(struct kvm_vcpu *vcpu, u64 id,
--
1.8.1.4
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PULL 2/3] KVM: PPC: Book3S HV: Endian fix for accessing VPA yield count
2015-03-25 21:58 ` Alexander Graf
@ 2015-03-25 21:58 ` Alexander Graf
-1 siblings, 0 replies; 10+ messages in thread
From: Alexander Graf @ 2015-03-25 21:58 UTC (permalink / raw)
To: kvm-ppc; +Cc: kvm, pbonzini, mtosatti, Paul Mackerras
From: Paul Mackerras <paulus@samba.org>
The VPA (virtual processor area) is defined by PAPR and is therefore
big-endian, so we need a be32_to_cpu when reading it in
kvmppc_get_yield_count(). Without this, H_CONFER always fails on a
little-endian host, causing SMP guests to waste time spinning on
spinlocks.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/book3s_hv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index b273193..de74756 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -636,7 +636,7 @@ static int kvmppc_get_yield_count(struct kvm_vcpu *vcpu)
spin_lock(&vcpu->arch.vpa_update_lock);
lppaca = (struct lppaca *)vcpu->arch.vpa.pinned_addr;
if (lppaca)
- yield_count = lppaca->yield_count;
+ yield_count = be32_to_cpu(lppaca->yield_count);
spin_unlock(&vcpu->arch.vpa_update_lock);
return yield_count;
}
--
1.8.1.4
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PULL 2/3] KVM: PPC: Book3S HV: Endian fix for accessing VPA yield count
@ 2015-03-25 21:58 ` Alexander Graf
0 siblings, 0 replies; 10+ messages in thread
From: Alexander Graf @ 2015-03-25 21:58 UTC (permalink / raw)
To: kvm-ppc; +Cc: kvm, pbonzini, mtosatti, Paul Mackerras
From: Paul Mackerras <paulus@samba.org>
The VPA (virtual processor area) is defined by PAPR and is therefore
big-endian, so we need a be32_to_cpu when reading it in
kvmppc_get_yield_count(). Without this, H_CONFER always fails on a
little-endian host, causing SMP guests to waste time spinning on
spinlocks.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/book3s_hv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index b273193..de74756 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -636,7 +636,7 @@ static int kvmppc_get_yield_count(struct kvm_vcpu *vcpu)
spin_lock(&vcpu->arch.vpa_update_lock);
lppaca = (struct lppaca *)vcpu->arch.vpa.pinned_addr;
if (lppaca)
- yield_count = lppaca->yield_count;
+ yield_count = be32_to_cpu(lppaca->yield_count);
spin_unlock(&vcpu->arch.vpa_update_lock);
return yield_count;
}
--
1.8.1.4
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PULL 3/3] KVM: PPC: Book3S HV: Fix instruction emulation
2015-03-25 21:58 ` Alexander Graf
@ 2015-03-25 21:58 ` Alexander Graf
-1 siblings, 0 replies; 10+ messages in thread
From: Alexander Graf @ 2015-03-25 21:58 UTC (permalink / raw)
To: kvm-ppc; +Cc: kvm, pbonzini, mtosatti, Paul Mackerras
From: Paul Mackerras <paulus@samba.org>
Commit 4a157d61b48c ("KVM: PPC: Book3S HV: Fix endianness of
instruction obtained from HEIR register") had the side effect that
we no longer reset vcpu->arch.last_inst to -1 on guest exit in
the cases where the instruction is not fetched from the guest.
This means that if instruction emulation turns out to be required
in those cases, the host will emulate the wrong instruction, since
vcpu->arch.last_inst will contain the last instruction that was
emulated.
This fixes it by making sure that vcpu->arch.last_inst is reset
to -1 in those cases.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index bb94e6f..6cbf163 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -1005,6 +1005,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
/* Save HEIR (HV emulation assist reg) in emul_inst
if this is an HEI (HV emulation interrupt, e40) */
li r3,KVM_INST_FETCH_FAILED
+ stw r3,VCPU_LAST_INST(r9)
cmpwi r12,BOOK3S_INTERRUPT_H_EMUL_ASSIST
bne 11f
mfspr r3,SPRN_HEIR
--
1.8.1.4
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PULL 3/3] KVM: PPC: Book3S HV: Fix instruction emulation
@ 2015-03-25 21:58 ` Alexander Graf
0 siblings, 0 replies; 10+ messages in thread
From: Alexander Graf @ 2015-03-25 21:58 UTC (permalink / raw)
To: kvm-ppc; +Cc: kvm, pbonzini, mtosatti, Paul Mackerras
From: Paul Mackerras <paulus@samba.org>
Commit 4a157d61b48c ("KVM: PPC: Book3S HV: Fix endianness of
instruction obtained from HEIR register") had the side effect that
we no longer reset vcpu->arch.last_inst to -1 on guest exit in
the cases where the instruction is not fetched from the guest.
This means that if instruction emulation turns out to be required
in those cases, the host will emulate the wrong instruction, since
vcpu->arch.last_inst will contain the last instruction that was
emulated.
This fixes it by making sure that vcpu->arch.last_inst is reset
to -1 in those cases.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index bb94e6f..6cbf163 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -1005,6 +1005,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
/* Save HEIR (HV emulation assist reg) in emul_inst
if this is an HEI (HV emulation interrupt, e40) */
li r3,KVM_INST_FETCH_FAILED
+ stw r3,VCPU_LAST_INST(r9)
cmpwi r12,BOOK3S_INTERRUPT_H_EMUL_ASSIST
bne 11f
mfspr r3,SPRN_HEIR
--
1.8.1.4
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PULL 0/3] 4.0 patch queue 2015-03-25
2015-03-25 21:58 ` Alexander Graf
@ 2015-03-25 23:20 ` Marcelo Tosatti
-1 siblings, 0 replies; 10+ messages in thread
From: Marcelo Tosatti @ 2015-03-25 23:20 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-ppc, kvm, pbonzini
On Wed, Mar 25, 2015 at 10:58:54PM +0100, Alexander Graf wrote:
> Hi Paolo,
>
> This is my current patch queue for 4.0. Please pull.
>
> Alex
>
>
> The following changes since commit f710a12d73dfa1c3a5d2417f2482b970f03bb850:
>
> Merge tag 'kvm-arm-fixes-4.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm (2015-03-16 20:08:56 -0300)
>
> are available in the git repository at:
>
>
> git://github.com/agraf/linux-2.6.git tags/signed-for-4.0
>
> for you to fetch changes up to 2bf27601c7b50b6ced72f27304109dc52eb52919:
>
> KVM: PPC: Book3S HV: Fix instruction emulation (2015-03-20 11:42:33 +0100)
Pulled, thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PULL 0/3] 4.0 patch queue 2015-03-25
@ 2015-03-25 23:20 ` Marcelo Tosatti
0 siblings, 0 replies; 10+ messages in thread
From: Marcelo Tosatti @ 2015-03-25 23:20 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-ppc, kvm, pbonzini
On Wed, Mar 25, 2015 at 10:58:54PM +0100, Alexander Graf wrote:
> Hi Paolo,
>
> This is my current patch queue for 4.0. Please pull.
>
> Alex
>
>
> The following changes since commit f710a12d73dfa1c3a5d2417f2482b970f03bb850:
>
> Merge tag 'kvm-arm-fixes-4.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm (2015-03-16 20:08:56 -0300)
>
> are available in the git repository at:
>
>
> git://github.com/agraf/linux-2.6.git tags/signed-for-4.0
>
> for you to fetch changes up to 2bf27601c7b50b6ced72f27304109dc52eb52919:
>
> KVM: PPC: Book3S HV: Fix instruction emulation (2015-03-20 11:42:33 +0100)
Pulled, thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-03-25 23:20 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-25 21:58 [PULL 0/3] 4.0 patch queue 2015-03-25 Alexander Graf
2015-03-25 21:58 ` Alexander Graf
2015-03-25 21:58 ` [PULL 1/3] KVM: PPC: Book3S HV: Fix spinlock/mutex ordering issue in kvmppc_set_lpcr() Alexander Graf
2015-03-25 21:58 ` Alexander Graf
2015-03-25 21:58 ` [PULL 2/3] KVM: PPC: Book3S HV: Endian fix for accessing VPA yield count Alexander Graf
2015-03-25 21:58 ` Alexander Graf
2015-03-25 21:58 ` [PULL 3/3] KVM: PPC: Book3S HV: Fix instruction emulation Alexander Graf
2015-03-25 21:58 ` Alexander Graf
2015-03-25 23:20 ` [PULL 0/3] 4.0 patch queue 2015-03-25 Marcelo Tosatti
2015-03-25 23:20 ` Marcelo Tosatti
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.