From patchwork Thu Sep 19 06:02:45 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bharat Bhushan X-Patchwork-Id: 275873 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id CAE0D2C016A for ; Thu, 19 Sep 2013 16:10:52 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752735Ab3ISGKv (ORCPT ); Thu, 19 Sep 2013 02:10:51 -0400 Received: from mail-db8lp0187.outbound.messaging.microsoft.com ([213.199.154.187]:16654 "EHLO db8outboundpool.messaging.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752515Ab3ISGKv (ORCPT ); Thu, 19 Sep 2013 02:10:51 -0400 Received: from mail43-db8-R.bigfish.com (10.174.8.243) by DB8EHSOBE009.bigfish.com (10.174.4.72) with Microsoft SMTP Server id 14.1.225.22; Thu, 19 Sep 2013 06:10:49 +0000 Received: from mail43-db8 (localhost [127.0.0.1]) by mail43-db8-R.bigfish.com (Postfix) with ESMTP id A0E61440198; Thu, 19 Sep 2013 06:10:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI; H:mail.freescale.net; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VS3(zzzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h1de097h8275bhz2dh2a8h839he5bhf0ah107ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h1155h) Received: from mail43-db8 (localhost.localdomain [127.0.0.1]) by mail43-db8 (MessageSwitch) id 1379571047698292_27281; Thu, 19 Sep 2013 06:10:47 +0000 (UTC) Received: from DB8EHSMHS009.bigfish.com (unknown [10.174.8.241]) by mail43-db8.bigfish.com (Postfix) with ESMTP id 9BFBA46018C; Thu, 19 Sep 2013 06:10:47 +0000 (UTC) Received: from mail.freescale.net (70.37.183.190) by DB8EHSMHS009.bigfish.com (10.174.4.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 19 Sep 2013 06:10:46 +0000 Received: from az84smr01.freescale.net (10.64.34.197) by 039-SN1MMR1-003.039d.mgd.msft.net (10.84.1.16) with Microsoft SMTP Server (TLS) id 14.3.158.2; Thu, 19 Sep 2013 06:10:40 +0000 Received: from freescale.com ([10.232.15.72]) by az84smr01.freescale.net (8.14.3/8.14.0) with SMTP id r8J6AYME022657; Wed, 18 Sep 2013 23:10:35 -0700 Received: by freescale.com (sSMTP sendmail emulation); Thu, 19 Sep 2013 11:33:21 +0530 From: Bharat Bhushan To: , , , , , , CC: Bharat Bhushan , Bharat Bhushan Subject: [PATCH 5/6 v5] kvm: booke: clear host tlb reference flag on guest tlb invalidation Date: Thu, 19 Sep 2013 11:32:45 +0530 Message-ID: <1379570566-3715-6-git-send-email-Bharat.Bhushan@freescale.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <1379570566-3715-1-git-send-email-Bharat.Bhushan@freescale.com> References: <1379570566-3715-1-git-send-email-Bharat.Bhushan@freescale.com> MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Sender: kvm-ppc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm-ppc@vger.kernel.org On booke, "struct tlbe_ref" contains host tlb mapping information (pfn: for guest-pfn to pfn, flags: attribute associated with this mapping) for a guest tlb entry. So when a guest creates a TLB entry then "struct tlbe_ref" is set to point to valid "pfn" and set attributes in "flags" field of the above said structure. When a guest TLB entry is invalidated then flags field of corresponding "struct tlbe_ref" is updated to point that this is no more valid, also we selectively clear some other attribute bits, example: if E500_TLB_BITMAP was set then we clear E500_TLB_BITMAP, if E500_TLB_TLB0 is set then we clear this. Ideally we should clear complete "flags" as this entry is invalid and does not have anything to re-used. The other part of the problem is that when we use the same entry again then also we do not clear (started doing or-ing etc). So far it was working because the selectively clearing mentioned above actually clears "flags" what was set during TLB mapping. But the problem starts coming when we add more attributes to this then we need to selectively clear them and which is not needed. This patch we do both - Clear "flags" when invalidating; - Clear "flags" when reusing same entry later Signed-off-by: Bharat Bhushan --- v3-> v5 - New patch (found this issue when doing vfio-pci development) arch/powerpc/kvm/e500_mmu_host.c | 12 +++++++----- 1 files changed, 7 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c index 1c6a9d7..60f5a3c 100644 --- a/arch/powerpc/kvm/e500_mmu_host.c +++ b/arch/powerpc/kvm/e500_mmu_host.c @@ -217,7 +217,8 @@ void inval_gtlbe_on_host(struct kvmppc_vcpu_e500 *vcpu_e500, int tlbsel, } mb(); vcpu_e500->g2h_tlb1_map[esel] = 0; - ref->flags &= ~(E500_TLB_BITMAP | E500_TLB_VALID); + /* Clear flags as TLB is not backed by the host anymore */ + ref->flags = 0; local_irq_restore(flags); } @@ -227,7 +228,8 @@ void inval_gtlbe_on_host(struct kvmppc_vcpu_e500 *vcpu_e500, int tlbsel, * rarely and is not worth optimizing. Invalidate everything. */ kvmppc_e500_tlbil_all(vcpu_e500); - ref->flags &= ~(E500_TLB_TLB0 | E500_TLB_VALID); + /* Clear flags as TLB is not backed by the host anymore */ + ref->flags = 0; } /* Already invalidated in between */ @@ -237,8 +239,8 @@ void inval_gtlbe_on_host(struct kvmppc_vcpu_e500 *vcpu_e500, int tlbsel, /* Guest tlbe is backed by at most one host tlbe per shadow pid. */ kvmppc_e500_tlbil_one(vcpu_e500, gtlbe); - /* Mark the TLB as not backed by the host anymore */ - ref->flags &= ~E500_TLB_VALID; + /* Clear flags as TLB is not backed by the host anymore */ + ref->flags = 0; } static inline int tlbe_is_writable(struct kvm_book3e_206_tlb_entry *tlbe) @@ -251,7 +253,7 @@ static inline void kvmppc_e500_ref_setup(struct tlbe_ref *ref, pfn_t pfn) { ref->pfn = pfn; - ref->flags |= E500_TLB_VALID; + ref->flags = E500_TLB_VALID; if (tlbe_is_writable(gtlbe)) kvm_set_pfn_dirty(pfn);