From patchwork Fri Sep 25 21:18:48 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rex Feany X-Patchwork-Id: 34309 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from bilbo.ozlabs.org (localhost [127.0.0.1]) by ozlabs.org (Postfix) with ESMTP id 807EFB7C53 for ; Sat, 26 Sep 2009 07:19:12 +1000 (EST) Received: by ozlabs.org (Postfix) id 62591B7B9C; Sat, 26 Sep 2009 07:19:05 +1000 (EST) Delivered-To: linuxppc-dev@ozlabs.org Received: from bos-spam.mrv.com (mx5.mrv.com [140.179.254.12]) by ozlabs.org (Postfix) with ESMTP id D9AEEB7B9B for ; Sat, 26 Sep 2009 07:19:04 +1000 (EST) X-ASG-Debug-ID: 1253913543-541700120001-myxymE Received: from bosmail.bos.mrv.com (bosmail.bos.mrv.com [140.179.176.26]) by bos-spam.mrv.com with ESMTP id ABIVroQBSv5T7S70; Fri, 25 Sep 2009 17:19:03 -0400 (EDT) X-Barracuda-Envelope-From: RFeany@mrv.com Received: from chmailsrv.int.mrv.com ([192.168.11.19]) by bosmail.bos.mrv.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Sep 2009 17:19:42 -0400 Received: from jane.chatsunix.int.mrv.com ([192.168.11.80]) by chmailsrv.int.mrv.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 14:19:40 -0700 X-Barracuda-BBL-IP: 192.168.11.19 X-Barracuda-RBL-IP: 192.168.11.19 Received: from compile2.chatsunix.int.mrv.com ([192.168.17.15]) by jane.chatsunix.int.mrv.com with esmtp (Exim 4.69) (envelope-from ) id 1MrIBk-000803-Hu; Fri, 25 Sep 2009 14:18:48 -0700 Received: from rfeany by compile2.chatsunix.int.mrv.com with local (Exim 4.69) (envelope-from ) id 1MrIBk-0001d0-Cv; Fri, 25 Sep 2009 14:18:48 -0700 Date: Fri, 25 Sep 2009 14:18:48 -0700 From: Rex Feany To: Benjamin Herrenschmidt X-ASG-Orig-Subj: Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite Subject: Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite Message-ID: <20090925211848.GA3371@compile2.chatsunix.int.mrv.com> References: <20090924004552.GA11737@compile2.chatsunix.int.mrv.com> <1253774659.7103.405.camel@pasglop> <20090924233346.GA445@compile2.chatsunix.int.mrv.com> <1253836376.7103.469.camel@pasglop> <20090925013528.GA2584@compile2.chatsunix.int.mrv.com> <1253843480.7103.492.camel@pasglop> <1253847827.7103.504.camel@pasglop> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1253847827.7103.504.camel@pasglop> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 25 Sep 2009 21:19:40.0592 (UTC) FILETIME=[E4BF1300:01CA3E25] X-Barracuda-Connect: bosmail.bos.mrv.com[140.179.176.26] X-Barracuda-Start-Time: 1253913543 X-Barracuda-URL: http://140.179.128.126:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at mrv.com Cc: "linuxppc-dev@ozlabs.org" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org Thus spake Benjamin Herrenschmidt (benh@kernel.crashing.org): > > > I think there's more finishyness to 8xx than we thought. IE. That > > tlbil_va might have more reasons to be there than what the comment > > seems to advertize. Can you try to move it even higher up ? IE. > > Unconditionally at the beginning of set_pte_filter ? > > > > Also, if that doesn't help, can you try putting one in > > set_access_flags_filter() just below ? > > Ok, I got a refresher on the whole concept of "unpopulated TLB entries" > on 8xx, and that's damn scary. I think what mislead me initially is that > the comment around the workaround is simply not properly describing the > extent of the problem :-) Oh boy, that sounds bad. Where is a good place to read about this? > So I'm not going to make the 8xx TLB miss code sane, that's beyond what > I'm prepare to do with it, but I suspect that this should fix it (on top > of upstream). Let me know if that's enough or if we also need to put > one of these in ptep_set_access_flags(). > > Please let me know if that works for you. Putting the tlbil_va() in the top of set_pte_filter() doesn't work - it hangs on boot before it even prints any messages to the console. However, adding tlbil_va() to ptep_set_access_flags() as you suggested makes everything happy. I need to test it some more, but it looks good so far. Below is what I am testing now. thanks! /rex. diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c index 5304093..aef552a 100644 --- a/arch/powerpc/mm/pgtable.c +++ b/arch/powerpc/mm/pgtable.c @@ -176,18 +176,19 @@ static pte_t set_pte_filter(pte_t pte, unsigned long addr) struct page *pg = maybe_pte_to_page(pte); if (!pg) return pte; - if (!test_bit(PG_arch_1, &pg->flags)) { #ifdef CONFIG_8xx - /* On 8xx, cache control instructions (particularly - * "dcbst" from flush_dcache_icache) fault as write - * operation if there is an unpopulated TLB entry - * for the address in question. To workaround that, - * we invalidate the TLB here, thus avoiding dcbst - * misbehaviour. - */ - /* 8xx doesn't care about PID, size or ind args */ - _tlbil_va(addr, 0, 0, 0); + /* On 8xx, cache control instructions (particularly + * "dcbst" from flush_dcache_icache) fault as write + * operation if there is an unpopulated TLB entry + * for the address in question. To workaround that, + * we invalidate the TLB here, thus avoiding dcbst + * misbehaviour. + */ + /* 8xx doesn't care about PID, size or ind args */ + _tlbil_va(addr, 0, 0, 0); #endif /* CONFIG_8xx */ + + if (!test_bit(PG_arch_1, &pg->flags)) { flush_dcache_icache_page(pg); set_bit(PG_arch_1, &pg->flags); } @@ -308,6 +309,12 @@ int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long address, int changed; entry = set_access_flags_filter(entry, vma, dirty); changed = !pte_same(*(ptep), entry); + +#ifdef CONFIG_8xx + /* 8xx doesn't care about PID, size or ind args */ + _tlbil_va(address, 0, 0, 0); +#endif /* CONFIG_8xx */ + if (changed) { if (!(vma->vm_flags & VM_HUGETLB)) assert_pte_locked(vma->vm_mm, address);