From owner-svn-src-all@freebsd.org Fri Oct 14 17:55:43 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 6DC51C12BE4; Fri, 14 Oct 2016 17:55:43 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 4041A1D21; Fri, 14 Oct 2016 17:55:43 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 14 Oct 2016 11:08:42 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.15.2/8.14.4) with ESMTP id u9EHtgG4069054; Fri, 14 Oct 2016 10:55:42 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.15.2/8.14.4/Submit) id u9EHtgtb069053; Fri, 14 Oct 2016 10:55:42 -0700 (PDT) (envelope-from ambrisko) Date: Fri, 14 Oct 2016 10:55:42 -0700 From: Doug Ambrisko To: Ravi Pokala Cc: Warner Losh , Doug Ambrisko , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader Message-ID: <20161014175542.GB65545@ambrisko.com> References: <201610141710.u9EHArlL089412@repo.freebsd.org> <20161014172705.GA65545@ambrisko.com> <3FF8A9D8-0C8A-4033-A7FC-8B64E9AB025F@panasas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FF8A9D8-0C8A-4033-A7FC-8B64E9AB025F@panasas.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 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: Fri, 14 Oct 2016 17:55:43 -0000 On Fri, Oct 14, 2016 at 10:33:15AM -0700, Ravi Pokala wrote: | -----Original Message----- | > From: on behalf of Doug Ambrisko | > Date: 2016-10-14, Friday at 10:27 | > To: Warner Losh | > Cc: Doug Ambrisko , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" | > Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader | > | > On Fri, Oct 14, 2016 at 11:16:02AM -0600, Warner Losh wrote: | > | Love the functionality, but don't like using the 'hint' namespace for | > | this. Can we change it now before too many things depend on it? We had | > | similar issues in ACPI and moved it to the 'acpi' space. Can we move | > | this to the 'smbios' space please? | > | | > | The reason is that 'hint' is special and sometimes filtered out, so it | > | is a poor choice to export data from the boot loader to the kernel. | > | > The reason I picked hint was it could be put /boot/device.hints | > to make it work as well and that it was a hint. Other standards in the | > future might use other methods. Looking back over the email I had | > with John he had suggested hint.smbios.0.anchor to make this look | > different. This code had been hanging around for so long I forgot | > about that and we were using hint.smbios.0.mem in our shipping code base. | > | > However, I hope that nothing would use this except for smbios(4) and | > for people to make smbios(4) useful for this info. | | Doug's looking at me when he says that. :-) | | We talked about this last night at BAFUG; right now, even if smbios(4) | is able to find the SMBIOS info -- it currently only looks at the | aforementioned 0xf0000 - 0xfffff range, so it can't find it on UEFI -- | smbios(4) doesn't actually provide any interface for that information. | Doug and I have talked about making smbios(4) useful, by parsing the | data and providing KPIs and APIs, for years now; I think I'll *finally* | have the time and motivation to do so "soon". I've actually talked to a few people. However, your the first to step up. This needs to be designed and will take some time and review. I would hope that except for smbios(4), nothing else would use this kenv but there is nothing to prevent that :-( I could name it super_secret_dont_use. BTW, to get you started this patch prevents smbios(4) from blowing chunks when it gets a anchor in high memory and works on legacy machines. --- /sys/x86/bios/smbios.c 2013-10-01 14:28:25.000000000 -0700 +++ ./smbios.c 2016-04-11 11:58:03.234969000 -0700 @@ -38,6 +38,7 @@ __FBSDID("$FreeBSD: release/9.2.0/sys/x8 #include #include #include +#include #include #include @@ -59,7 +60,7 @@ struct smbios_softc { }; #define RES2EPS(res) ((struct smbios_eps *)rman_get_virtual(res)) -#define ADDR2EPS(addr) ((struct smbios_eps *)BIOS_PADDRTOVADDR(addr)) +#define ADDR2EPS(addr) ((struct smbios_eps *)PHYS_TO_DMAP(addr)) static devclass_t smbios_devclass; @@ -71,19 +72,26 @@ static int smbios_modevent (module_t, in static int smbios_cksum (struct smbios_eps *); +static unsigned long addr; +static SYSCTL_NODE(_hw, OID_AUTO, smbios, CTLFLAG_RD, 0, + "SMBIOS driver parameters"); +SYSCTL_LONG(_hw_smbios, OID_AUTO, mem, CTLFLAG_RW, + &addr, 0, ""); + static void smbios_identify (driver_t *driver, device_t parent) { device_t child; - u_int32_t addr; int length; int rid; if (!device_is_alive(parent)) return; - addr = bios_sigsearch(SMBIOS_START, SMBIOS_SIG, SMBIOS_LEN, - SMBIOS_STEP, SMBIOS_OFF); + if (resource_long_value("smbios", 0, "mem", &addr) != 0 || + addr == 0) + addr = bios_sigsearch(SMBIOS_START, SMBIOS_SIG, SMBIOS_LEN, + SMBIOS_STEP, SMBIOS_OFF); if (addr != 0) { rid = 0; length = ADDR2EPS(addr)->length; Note I don't plan to commit this since it doesn't really do much and we need a lot more. Thanks, Doug A.