From owner-svn-src-all@freebsd.org Thu Apr 14 17:00:07 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 52D2EADAE22 for ; Thu, 14 Apr 2016 17:00:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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)) by mx1.freebsd.org (Postfix) with ESMTPS id 195E21435 for ; Thu, 14 Apr 2016 17:00:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id g185so109895248ioa.2 for ; Thu, 14 Apr 2016 10:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=u8vX+KAeH2pQ0jOzDLRLMKH/u1T8eM0lpnLi4pbfsls=; b=uDAfOWj85wzYRrYMNjr2H8nk41sggmbeDc55h44GdNbV1+6uQuL9vwEC7UN1jn/H/8 nfmRs2/H2OMvbuNS2HDwO5r+3Jg7ClJaziejYTUmTNZtGlfXSGhuN58v8BMxpmhoP8H2 yTHVSgXZbE/8+uJWWUL/ADj7LpN691qcOx3RpGRmn6DL0PlIam4EBQ/KRwtxE4Yh2erv lh2jo9R/vp7Za2drroKnuSD2P+aQw90yKZtIJ5bieXHSAUZFCnBk/hh8w0rswTcc/8AG IaBEe8qihH09B2pVp2aUXzua2Tfx11lDcq2h6t30FYUkv6p+xgGYVuDdTsg3rAQAOHix 4HnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=u8vX+KAeH2pQ0jOzDLRLMKH/u1T8eM0lpnLi4pbfsls=; b=i7y/Jo2nJ8ofhXTcJzfkB9EARVsdooQ/VxOODtthW43LZvJu+KnivnLHmVd12UNN/r hkiTDAMzLgPuRjZnCOEoLl93Aqbg7i/0WM6k0YfbioIInNifTmgnH6Hy77uPhiBnMWKz Y+C4wSV4SnMzakQTVQFHSLBczFX3T7s0WUYYqAJLu23iCk/ZsSVHKUbJnC9FKAmwo0BK 7XlxHxQI+EgnVjIcVlcknT1H73I6sXgbGYCqnLh4b9nhMzju/K8cPFnbS/ShTbHyj3xA DlY62Nhb+K0NP1dUWhE/kXWfE6vsPsSgzZJNwCWCHr7lRVzsvuHY4a2eOV/isy8wibnI /VEw== X-Gm-Message-State: AOPr4FWeP1Vftc7aiKuBpGJQ4r8oA5bn7lOgEOrjKSHHMtDqNYcao012T/uKmiROxqadQsBf1D4mYj+KEwqgTQ== MIME-Version: 1.0 X-Received: by 10.107.11.223 with SMTP id 92mr16496303iol.59.1460653206180; Thu, 14 Apr 2016 10:00:06 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.194.3 with HTTP; Thu, 14 Apr 2016 10:00:06 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <1460652564.52955.28.camel@freebsd.org> References: <201604140459.u3E4xpYv038183@repo.freebsd.org> <20160414092229.1ba8d6c5@zapp> <1460652564.52955.28.camel@freebsd.org> Date: Thu, 14 Apr 2016 11:00:06 -0600 X-Google-Sender-Auth: 9LvVFZohOPJbvlWCKJ6G9pkR3CE Message-ID: Subject: Re: svn commit: r297954 - in head/sys: boot/efi/loader/arch/amd64 boot/i386/libi386 x86/acpica From: Warner Losh To: Ian Lepore Cc: Andrew Turner , Warner Losh , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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 17:00:07 -0000 On Thu, Apr 14, 2016 at 10:49 AM, Ian Lepore wrote: > 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. I'd support exporting it to the kernel via module data. That's more secure anyway, and can be expanded to other bits of data that need to be communicated between the bootloader and kernel that one may not wish to otherwise disclose. It certainly would clear up one ugly wart on the kernel environment and make further cleanups possible and a sane undertaking. Warner > > -- 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 >