From owner-svn-src-all@freebsd.org Thu Apr 14 16:49:32 2016 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 9DE0BADA999 for ; Thu, 14 Apr 2016 16:49:32 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 814E51D0E for ; Thu, 14 Apr 2016 16:49:32 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: dc464ad3-0260-11e6-9fea-b54670b854a5 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 14 Apr 2016 16:49:31 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u3EGnOXu021928; Thu, 14 Apr 2016 10:49:24 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1460652564.52955.28.camel@freebsd.org> Subject: Re: svn commit: r297954 - in head/sys: boot/efi/loader/arch/amd64 boot/i386/libi386 x86/acpica From: Ian Lepore To: Warner Losh , Andrew Turner Cc: Warner Losh , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Date: Thu, 14 Apr 2016 10:49:24 -0600 In-Reply-To: References: <201604140459.u3E4xpYv038183@repo.freebsd.org> <20160414092229.1ba8d6c5@zapp> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.21 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: Thu, 14 Apr 2016 16:49:32 -0000 On Thu, 2016-04-14 at 10:43 -0600, Warner Losh wrote: > On Thu, Apr 14, 2016 at 2:22 AM, Andrew Turner > wrote: > > > On Thu, 14 Apr 2016 04:59:51 +0000 (UTC) > > Warner Losh wrote: > > > > > Author: imp > > > Date: Thu Apr 14 04:59:51 2016 > > > New Revision: 297954 > > > URL: https://svnweb.freebsd.org/changeset/base/297954 > > > > > > Log: > > > Deprecate using hints.acpi.0.rsdp to communicate the RSDP to > > > the > > > system. This uses the hints mechnanism. This mostly works today > > > because when there's no static hints (the default), this value > > > can > > > be fetched from the hint. When there is a static hints file, the > > > hint > > > passed from the boot loader to the kernel is ignored, but for > > > the > > > BIOS case we're able to find it anyway. However, with UEFI, the > > > fallback doesn't work, so we get a panic instead. > > > > > > Switch to acpi.rsdp and use TUNABLE_ULONG_FETCH instead. > > > Continue to > > > generate the old values to allow for transitions. In addition, > > > fall > > > back to the old method if the new method isn't present. > > > > > > Add comments about all this. > > > > > > Differential Revision: https://reviews.freebsd.org/D5866 > > > > Why not pass it in using module data as we do with the DTB? It > > would > > fix issues where we have either or both static hints and a stat > > env. > > > > I viewed that as brittle. And it was longer to code. This works with > static > hints, but not static env. Static env tends not to be used on x86. > > I'm open to putting it into module data as a more robust solution. I > just > didn't have the extra time it would take to do so at the moment. > Another thing that I think should be passed the way we pass loaded modules is GELI password and/or key data. It's currently passed in the environment, and static env subverts that. While static env has mostly been an embedded-system thing to date, there is more x86 embedded hardware hitting the market these days. Maybe we need some helper code to make it easy to encapsulate data in a module-like form on the loader side, and access it from the kernel side, to make it easier to pass binary data from the loader without having to ascii-encode it into the environment. -- Ian > > > Whatever method is decided we will also need it on arm64 as we > > claim to > > support ACPI there, although no backwards compatibility will be > > needed > > as the code is most likely broken as it's only partially been > > tested. > > > > Yes. The issue is with ACPI + UEFI. With ACPI + BIOS, we could find > things always, and this didn't matter. This change doesn't change > that. > But for UEFI, the RSDP table can be (and often is) located in areas > the code doesn't search. > > We likely need to unify more than just passing in the RSDP, since if > we want > to callout to UEFI after the kernel has booted, there's a number of > other > things that need to be passed as well. I have a review that gets this > working > on x86 that I'll open up when more of my backlog has been pushed into > the tree. I'll be sure to include you. > > Warner