From owner-freebsd-hackers@freebsd.org Wed Jun 13 16:26:18 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0341E101ACB8 for ; Wed, 13 Jun 2018 16:26:18 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 7C84C6C31C for ; Wed, 13 Jun 2018 16:26:17 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 38d538b5-6f24-11e8-afd2-4ddcc8249dd4 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 38d538b5-6f24-11e8-afd2-4ddcc8249dd4; Wed, 13 Jun 2018 16:10:01 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w5DG9xqI060862; Wed, 13 Jun 2018 10:09:59 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1528906199.12122.64.camel@freebsd.org> Subject: Re: specifying alignment of loader files From: Ian Lepore To: Mark Johnston , Warner Losh Cc: "freebsd-hackers@freebsd.org" Date: Wed, 13 Jun 2018 10:09:59 -0600 In-Reply-To: <20180612180544.GG56138@raichu> References: <20180612170420.GD56138@raichu> <20180612171649.GE56138@raichu> <20180612175130.GF56138@raichu> <20180612180544.GG56138@raichu> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 16:26:18 -0000 On Tue, 2018-06-12 at 14:05 -0400, Mark Johnston wrote: > On Tue, Jun 12, 2018 at 11:55:27AM -0600, Warner Losh wrote: > > > > On Tue, Jun 12, 2018 at 11:51 AM, Mark Johnston > > wrote: > > > > > > > > On Tue, Jun 12, 2018 at 11:45:01AM -0600, Warner Losh wrote: > > > > > > > > On Tue, Jun 12, 2018 at 11:16 AM, Mark Johnston > > > org> > > > wrote: > > > > > > > > > > > > > > > > > > On Tue, Jun 12, 2018 at 11:11:25AM -0600, Warner Losh wrote: > > > > > > > > > > > > On Tue, Jun 12, 2018 at 11:04 AM, Mark Johnston > > > > > bsd.org> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I'm writing some code which processes a file loaded by > > > > > > > the > > > loader.  I > > > > > > > > > > > > > > > > > > > > > > > > > > > > > want the file's contents to be available at a certain > > > > > > > alignment in > > > > > > > memory, and as far as I can see, the loader provides no > > > > > > > alignment > > > > > > > guarantees today.  The access will happen early enough > > > > > > > during boot > > > that > > > > > > > > > > > > > > > > > > > > > > > > > > > > > making an aligned copy of the data will be awkward, so > > > > > > > I'd like the > > > > > > > loader to provide the desired alignment. > > > > > > > > > > > > > > I'm considering adding a new "module_align" variable that > > > > > > > would > > > specify > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the alignment for a given file type, and plumb that > > > > > > > through to > > > > > > > command_load().  Does anyone have an alternate > > > > > > > suggestion, or an > > > > > > > objection to my proposal? > > > > > > > > > > > > > I thought the loader already did that for ELF sections... > > > > > > Why not > > > wrap > > > > > > > > > > > > > > your > > > > > > > > > > > > file in such a segment? > > > > > In this case it's a raw binary file (CPU microcode), and I > > > > > want to be > > > > > able to load it without any modifications or wrappers. > > > > > > > > > How do you identify the type then? I'm ok in theory with this > > > > (though a > > > > variable is more flexible than needed), but that's my main > > > > concern. > > > What's > > > > > > > > the alignment required btw? > > > It'd be a property of the type, e.g., > > > > > > cpu_ucode_name=/boot/firmware/... > > > cpu_ucode_align=16 > > > > > > I do feel like having a separate variable is overkill, but I > > > can't see > > > a less invasive solution that isn't hacky. > > > > > > The required alignment for Intel is 16 bytes; I'm not yet sure > > > whether > > > AMD has a required alignment. > > > > > OK. That seems sane. I was thinking it was more general than this, > > but I'm > > cool with what you've outlined. > > > > OTOH, wouldn't just loading all files on page boundaries suffice? > It would (and that's actually what I did in my test branch).  We > already have to do this for ELF, and the only other frequently loaded > file I can think of is /boot/entropy.  Can you think of any scenarios > where forcing page alignment for all files would waste a substantial > amount of memory?  If not, I might just go ahead with that approach > for > now and wait for a good reason before introducing customizable > alignments. There is already an arch_loadaddr() method in the archsw which is used to align every loaded module/file/whatever. I think not all arches implement it, but they probably should, and each arch should probably use the biggest possible cacheline size for that arch as the minimum alignment. For some arches, page boundaries might make sense.  A nice example is the beri implementation which does this:   /* Align ELF objects at page boundaries; others at cache lines. */   align = (type == LOAD_ELF) ? PAGE_SIZE : CACHE_LINE_SIZE;   return (roundup2(addr, align)); For a nice description of how the function is intended to work, see the comment block above uboot_loadaddr() in stand/uboot/lib/copy.c. -- Ian