From owner-freebsd-mips@freebsd.org Sun Nov 13 16:15:56 2016 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D5D6C400EF for ; Sun, 13 Nov 2016 16:15:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C61D1B6A; Sun, 13 Nov 2016 16:15:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uADGFmSR015585 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 13 Nov 2016 18:15:48 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uADGFmSR015585 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uADGFmii015584; Sun, 13 Nov 2016 18:15:48 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 13 Nov 2016 18:15:48 +0200 From: Konstantin Belousov To: Juli Mallett Cc: Warner Losh , Warner Losh , Adrian Chadd , "freebsd-mips@freebsd.org" Subject: Re: svn commit: r307626 - head/sys/ufs/ffs Message-ID: <20161113161548.GK54029@kib.kiev.ua> References: <201610191109.u9JB9TTC002727@repo.freebsd.org> <20161113065851.GD54029@kib.kiev.ua> <20161113071911.GF54029@kib.kiev.ua> <20161113075557.GH54029@kib.kiev.ua> <71C512CD-0FB6-40D8-B46C-30467A245693@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 16:15:56 -0000 On Sun, Nov 13, 2016 at 07:51:05AM -0800, Juli Mallett wrote: > On Sun, Nov 13, 2016 at 12:13 AM, Warner Losh wrote: > > [[ Moved to freebsd-mips and cc???d to Juli ]] > > > > That???s a very good question. Unfortunately my memory here fails me. I have a recollection that the various cache flushing that we do in the map ensures that we don???t hit a problem. However, I couldn???t construct a coherent answer to where this takes place after a brief look at the code. Multiple mappings will cause data corruption though. I wouldn???t have thought it causes the fault in question, but MIPS errors can manifest in strange ways, so perhaps you are correct. I don???t get how the fault address is 0 though from that scenario. Maybe Adrian can recall. Or Juli can help. > > As I recall, the "mips2" and Juniper code just punted on this, and the > current in-tree code did likewise. In fact, we explicitly use > aliasing in some places for short-term things through cached, > direct-mapped operations, with probably less than the requisite cache > ops to make VIPT processors work safely. > > There's also no set of cache ops you can put into pmap to make it safe > in general; attempts to do so probably haven't understood the scope of > the problem. We can end up with aliasing in the same process, so > doing it only on pmap activate doesn't prevent aliased accesses. You > could, if you want to really churn the TLB, allow only one active > mapping at a time and go through a trap to manage the mappings of > shared, cacheable pages. It's either that, or we have to, as Adrian > suggested, either mappings to uncached when persistent aliasing > occurs, or unshare those mappings, depending on whether the aliasing > is an optimization or a requirement for correctness. The easier thing > is probably to go through the PV mappings, and allow only one active > PTE at a time, and to eat the cost of all those traps for aliased > mappings, while remembering to be diligent about not allowing sharing > without copious cache flushing in the cases in the kernel where we > have temporary aliases using the direct map. Sparc64 also has the aliasing issue, and AFAIR sparc64 pmap does allow more than one mapping of the same page at conflicting ('differently colored') addresses. But indeed, each mapping (not only the managed mappings) are tracked, and all mappings are demoted to uncached if conflict is created. > > It'd be neat to see this happen; I'm not sure who would really do it. > It's tricky to get right. We may support other architectures that > have complete or partial solutions to this, but I deliberately don't > know about them. Stare at code dealing with VIPT ARM systems, or pmap > on other BSDs that have sunk more effort into all the edge cases of > VIPT MIPS systems. For arm, only arm v4 pmap deals with VIPT aliasing. Arm v6 assumes that the system is free from that bug.