From owner-freebsd-mips@freebsd.org Sun Nov 13 19:03:51 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 C337FC4084C for ; Sun, 13 Nov 2016 19:03:51 +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 6A6B312FE; Sun, 13 Nov 2016 19:03:51 +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 uADJ3i8Q062457 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 13 Nov 2016 21:03:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uADJ3i8Q062457 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uADJ3i3e062456; Sun, 13 Nov 2016 21:03:44 +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 21:03:44 +0200 From: Konstantin Belousov To: Adrian Chadd Cc: Juli Mallett , Warner Losh , Warner Losh , "freebsd-mips@freebsd.org" Subject: Re: svn commit: r307626 - head/sys/ufs/ffs Message-ID: <20161113190344.GM54029@kib.kiev.ua> References: <20161113065851.GD54029@kib.kiev.ua> <20161113071911.GF54029@kib.kiev.ua> <20161113075557.GH54029@kib.kiev.ua> <71C512CD-0FB6-40D8-B46C-30467A245693@bsdimp.com> <20161113161548.GK54029@kib.kiev.ua> 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 19:03:51 -0000 On Sun, Nov 13, 2016 at 10:50:19AM -0800, Adrian Chadd wrote: > Ok, so after talking with others, my questions are: > > * I thought our VM was supposed to not be doing double mapping like > this. warner's comment on irc was: > > === > 13:39 < bsdimp> adrian the VM isn't supposed to do it at all. > 13:39 < bsdimp> adrian that is, double map on purpose. > 13:40 < bsdimp> though there's some exceptions to the rule > 13:40 < bsdimp> since kernel mappings go away in userland, and > userland doesn't execute while you're in kernel mode, you can do the > flushing > game in busdma to prevent most issues. > 13:41 < bsdimp> which is what we do. Generally, though, our VM doesn't > do it in-kernel. > === > > * is this still the case? or are there places in the VM where we are doing this? > * can we introduce a machdep/pmap capability check to see if aliasing > is allowed and if so, turn this feature on? This never was the case, and never will. VM establishes mappings as requested by the userspace and kernel, and n-times mapping for the same page is always legitimate. It is the pmap duty to handle that. If you cared to read my previous mail, I already explained that besides the userspace asking for n-mapping, there is at least buffer cache which also maps the same page into KVA, from the times when unified buffer cache/page cache was introduced. Same is true for n-mapping of shared anon pages. > > Adding a pmap capability and turning it on for say, i386/amd64/arm64 > would allow for this new feature as well as the previous behaviour on > older platforms. > > I don't think I have the time to fix mips pmap to support this new > feature, so if you want to turn it on for all features, we should > really fix/test pmap on said platforms first. This is not a new feature, this is the old bug on that platform. > > Final comment: I'd really like to see a sort of "tested on" for things > like this, because it's not clear which platforms/architectures it was > tested on.