From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Mackerras Date: Sat, 22 Jun 2013 07:15:24 +0000 Subject: [PATCH 4/5] KVM: PPC: Book3S PR: Invalidate SLB entries properly Message-Id: <20130622071524.GE2791@iris.ozlabs.ibm.com> List-Id: References: <20130622071244.GA2791@iris.ozlabs.ibm.com> In-Reply-To: <20130622071244.GA2791@iris.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexander Graf , kvm-ppc@vger.kernel.org Cc: kvm@vger.kernel.org At present, if the guest creates a valid SLB (segment lookaside buffer) entry with the slbmte instruction, then invalidates it with the slbie instruction, then reads the entry with the slbmfee/slbmfev instructions, the result of the slbmfee will have the valid bit set, even though the entry is not actually considered valid by the host. This is confusing, if not worse. This fixes it by zeroing out the orige and origv fields of the SLB entry structure when the entry is invalidated. Signed-off-by: Paul Mackerras --- arch/powerpc/kvm/book3s_64_mmu.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kvm/book3s_64_mmu.c b/arch/powerpc/kvm/book3s_64_mmu.c index 2e93bb5..7519124 100644 --- a/arch/powerpc/kvm/book3s_64_mmu.c +++ b/arch/powerpc/kvm/book3s_64_mmu.c @@ -376,6 +376,8 @@ static void kvmppc_mmu_book3s_64_slbie(struct kvm_vcpu *vcpu, u64 ea) dprintk("KVM MMU: slbie(0x%llx, 0x%llx)\n", ea, slbe->esid); slbe->valid = false; + slbe->orige = 0; + slbe->origv = 0; kvmppc_mmu_map_segment(vcpu, ea); } @@ -386,8 +388,11 @@ static void kvmppc_mmu_book3s_64_slbia(struct kvm_vcpu *vcpu) dprintk("KVM MMU: slbia()\n"); - for (i = 1; i < vcpu->arch.slb_nr; i++) + for (i = 1; i < vcpu->arch.slb_nr; i++) { vcpu->arch.slb[i].valid = false; + vcpu->arch.slb[i].orige = 0; + vcpu->arch.slb[i].origv = 0; + } if (vcpu->arch.shared->msr & MSR_IR) { kvmppc_mmu_flush_segments(vcpu); -- 1.8.3.1 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Mackerras Subject: [PATCH 4/5] KVM: PPC: Book3S PR: Invalidate SLB entries properly Date: Sat, 22 Jun 2013 17:15:24 +1000 Message-ID: <20130622071524.GE2791@iris.ozlabs.ibm.com> References: <20130622071244.GA2791@iris.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org To: Alexander Graf , kvm-ppc@vger.kernel.org Return-path: Received: from ozlabs.org ([203.10.76.45]:50967 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751038Ab3FVHQh (ORCPT ); Sat, 22 Jun 2013 03:16:37 -0400 Content-Disposition: inline In-Reply-To: <20130622071244.GA2791@iris.ozlabs.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: At present, if the guest creates a valid SLB (segment lookaside buffer) entry with the slbmte instruction, then invalidates it with the slbie instruction, then reads the entry with the slbmfee/slbmfev instructions, the result of the slbmfee will have the valid bit set, even though the entry is not actually considered valid by the host. This is confusing, if not worse. This fixes it by zeroing out the orige and origv fields of the SLB entry structure when the entry is invalidated. Signed-off-by: Paul Mackerras --- arch/powerpc/kvm/book3s_64_mmu.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kvm/book3s_64_mmu.c b/arch/powerpc/kvm/book3s_64_mmu.c index 2e93bb5..7519124 100644 --- a/arch/powerpc/kvm/book3s_64_mmu.c +++ b/arch/powerpc/kvm/book3s_64_mmu.c @@ -376,6 +376,8 @@ static void kvmppc_mmu_book3s_64_slbie(struct kvm_vcpu *vcpu, u64 ea) dprintk("KVM MMU: slbie(0x%llx, 0x%llx)\n", ea, slbe->esid); slbe->valid = false; + slbe->orige = 0; + slbe->origv = 0; kvmppc_mmu_map_segment(vcpu, ea); } @@ -386,8 +388,11 @@ static void kvmppc_mmu_book3s_64_slbia(struct kvm_vcpu *vcpu) dprintk("KVM MMU: slbia()\n"); - for (i = 1; i < vcpu->arch.slb_nr; i++) + for (i = 1; i < vcpu->arch.slb_nr; i++) { vcpu->arch.slb[i].valid = false; + vcpu->arch.slb[i].orige = 0; + vcpu->arch.slb[i].origv = 0; + } if (vcpu->arch.shared->msr & MSR_IR) { kvmppc_mmu_flush_segments(vcpu); -- 1.8.3.1