From owner-freebsd-hackers@freebsd.org Tue Jun 12 18:01:19 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 B4760100DA64 for ; Tue, 12 Jun 2018 18:01:19 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F46572024 for ; Tue, 12 Jun 2018 18:01:19 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id F16091E64F for ; Tue, 12 Jun 2018 18:01:18 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf0-f45.google.com with SMTP id i83-v6so37395705lfh.5 for ; Tue, 12 Jun 2018 11:01:18 -0700 (PDT) X-Gm-Message-State: APt69E2KpV9isU27XqhALpW0BmIb+B3E86l+O/hCJz/SiVBEz3gMYNew XfAz+SIiDDJtpwbXX/JdHowpxYLYWL8TyefyjNo= X-Received: by 2002:a19:380a:: with SMTP id f10-v6mt929551lfa.47.1528826477477; Tue, 12 Jun 2018 11:01:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8582:0:0:0:0:0 with HTTP; Tue, 12 Jun 2018 11:00:56 -0700 (PDT) In-Reply-To: References: <20180612170420.GD56138@raichu> <20180612171649.GE56138@raichu> <20180612175130.GF56138@raichu> From: Kyle Evans Date: Tue, 12 Jun 2018 13:00:56 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: specifying alignment of loader files Cc: Warner Losh , Mark Johnston , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" 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: Tue, 12 Jun 2018 18:01:19 -0000 On Tue, Jun 12, 2018 at 1:00 PM, Kyle Evans wrote: > On Tue, Jun 12, 2018 at 12:55 PM, 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 >>> 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 >>> > > 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? > > If the answer to the above isn't "yes," can we consider making this a > flag to `load` parsed in command_load instead of its own > ${module}_align variable? e.g. > > cpu_ucode_name=/boot/firmware/... > cpu_ucode_flags="-a 16" > > The initial recommendation isn't a bad idea, > but adding a new ${module}_flags requires changes in both interpreters > that I'm not sure are strictly necessary when this will be relatively > rarely used. > > Thanks, > > Kyle Evans Sorry, that ${module}_flags should read ${module}_align.