From owner-svn-src-all@freebsd.org Mon Jan 15 17:53:43 2018 Return-Path: Delivered-To: svn-src-all@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 5BFA5EBE689; Mon, 15 Jan 2018 17:53:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E0FDC1E24; Mon, 15 Jan 2018 17:53:42 +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 w0FHrZcJ076698 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Jan 2018 19:53:38 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w0FHrZcJ076698 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w0FHrZ4a076697; Mon, 15 Jan 2018 19:53:35 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 15 Jan 2018 19:53:35 +0200 From: Konstantin Belousov To: Nathan Whitehorn Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r327950 - in head/sys/powerpc: aim include powerpc ps3 Message-ID: <20180115175335.GK1684@kib.kiev.ua> References: <20180114170502.GB1684@kib.kiev.ua> <184ba3ee-a9f7-01ed-bb02-1bcba9acc041@freebsd.org> <20180114175211.GD1684@kib.kiev.ua> <20180115111812.GF1684@kib.kiev.ua> <20180115170603.GJ1684@kib.kiev.ua> <9e5554d7-6a0c-5910-8cb6-74f98259536f@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9e5554d7-6a0c-5910-8cb6-74f98259536f@freebsd.org> User-Agent: Mutt/1.9.2 (2017-12-15) 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: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 17:53:43 -0000 On Mon, Jan 15, 2018 at 09:32:56AM -0800, Nathan Whitehorn wrote: > That seems fine to me. I don't think a less-clumsy way that does not > involve extra indirection is possible. The PHYS_TO_DMAP() returning NULL > is about the best thing I can come up with from a clumsiness standpoint > since plenty of code checks for null pointers already, but doesn't > cleanly handle the rarer case where you want to test for the existence > of direct maps in general without testing some potemkin address. > > My one reservation about PMAP_HAS_DMAP or the like as a selector is that > it does not encode the full shape of the problem: one could imagine > having a direct map that only covers a limited range of RAM (I am not > sure whether the existence of dmaplimit on amd64 implies this can happen > with non-device memory in real life), for example. These cases are > currently covered by an assert() in PHYS_TO_DMAP(), whereas having > PHYS_TO_DMAP() return NULL allows a more flexible signalling and the > potential for the calling code to do something reasonable to handle the > error. A single global flag can't convey information at this kind of > granularity. Is this a reasonable concern? Or am I overthinking things? IMO it is overreaction. amd64 assumes that all normal memory is covered by DMAP. It must never fail. See, for instance, the implementation of the sf bufs for it. If device memory not covered by DMAP can exists, it is the driver problem. For instance, for NVDIMMs I wrote specific mapping code which establishes kernel mapping for it, when not covered by EFI memory map and correspondingly not included into DMAP.