From owner-svn-src-all@freebsd.org Fri Oct 14 17:26:12 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 34CA2C1238F; Fri, 14 Oct 2016 17:26:12 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from mr11p00im-asmtp002.me.com (mr11p00im-asmtp002.me.com [17.110.69.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1859F7E2; Fri, 14 Oct 2016 17:26:12 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from process-dkim-sign-daemon.mr11p00im-asmtp002.me.com by mr11p00im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OF100300S5S3V00@mr11p00im-asmtp002.me.com>; Fri, 14 Oct 2016 17:26:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mac.com; s=4d515a; t=1476465966; bh=CLnjgBpsjqQdU2QVw8G04mzbN4t4okiMwl1lQCMbup4=; h=Date:Subject:From:To:Message-id:MIME-version:Content-type; b=sMMjixqVnp3/srRYLs53GdTeqCyg26aff0tvZ/HpjbN3Ntt9uELqZanfTUyZKAdP2 dNptJbBhUw50V3wDhCEnR9rE41RrLGLc/3Nl5GAI2SNtVl1BQ3PO9Zw9edUDag122a M7Ice8psKM3//tCpAoJc+n6qO8wnVl0n6sqwn+Flo6SFdoDkAib6PJ7T7InEmcMe0N n5RSMBnffP1Ofr5oAnkpiUq4TpmTyGSLrJm1dGeZ3ce7rvRk2JvrjheTNjNlJhJv0s e4To3UDCf6c+3VxoB4kD3EI4UUMYSyYXAWDBpDka3KHm14R1zyoh6GHuYeDtd6VqCH s31QLmt4KWpNQ== Received: from [192.168.1.4] (c-67-188-225-23.hsd1.ca.comcast.net [67.188.225.23]) by mr11p00im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OF100DNASFGC910@mr11p00im-asmtp002.me.com>; Fri, 14 Oct 2016 17:26:06 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-10-14_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1610140311 User-Agent: Microsoft-MacOutlook/f.1b.0.161010 Date: Fri, 14 Oct 2016 10:26:04 -0700 Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader From: Ravi Pokala Sender: "Pokala, Ravi" To: Warner Losh , Doug Ambrisko Cc: src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Message-id: <1D37BB03-A7B1-443B-B628-E712202D3934@panasas.com> Thread-topic: svn commit: r307326 - head/sys/boot/efi/loader References: <201610141710.u9EHArlL089412@repo.freebsd.org> In-reply-to: MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit 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:26:12 -0000 -----Original Message----- > From: on behalf of Warner Losh > Date: 2016-10-14, Friday at 10:16 > To: Doug Ambrisko > Cc: src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" > Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader > > Love the functionality, Ditto! Thank you Doug! :-) > 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. Loader already exports a bunch of stuff as "smbios.*" kenv variables. So perhaps "smbios.addr" or somesuch? Thanks, Ravi (rpokala@) > Warner > > On Fri, Oct 14, 2016 at 11:10 AM, Doug Ambrisko wrote: >> Author: ambrisko >> Date: Fri Oct 14 17:10:53 2016 >> New Revision: 307326 >> URL: https://svnweb.freebsd.org/changeset/base/307326 >> >> Log: >> In UEFI mode expose the SMBIOS anchor base address via kenv so the kernel >> etc. can find out where the SMBIOS entry point is located. In pure >> UEFI mode the BIOS is not mapped into the standard address space so the >> SMBIOS table might not appear between 0xf0000 and 0xfffff. The >> UEFI environment can report this the location of the anchor. If it is >> reported then expose it as hint.smbios.0.mem. This can then be used >> by other tools. However, we should make smbios(4) useful and have it >> take this value and provide accesor function so ipmi(4) etc. don't >> have to parse and figure things about the SMBIOS table. I have some >> simple patches to smbios(4) to expose this address as sysctl and >> for ipmi(4) to get the base address. However, the real fix is to >> have ipmi(4) ask smbios(4) for what it wants and have smbios(4) >> parse it out and return it. This would make smbios(4) useful and reduce >> duplicated code. If this address doesn't point to the anchor then >> finding SMBIOS info. will fail as if this didn't exist. So there should >> be no harm. >> >> With this change and the following hack, dmidecode works on a bunch of >> UEFI machines that I tested: >> >> if kenv hint.smbios.0.mem > /dev/null >> then >> mkdir -p /sys/firmware/efi >> mount -t tmpfs -o size=8k tmpfs /sys/firmware/efi >> echo "SMBIOS=`kenv hint.smbios.0.mem`" > /sys/firmware/efi/systab >> fi >> >> Linux exposes this information via the /sys/firmware/efi/systab file which >> dmidecode looks at. We should update dmidecode to do this the FreeBSD >> way when we determine what that is! >> >> Reviewed by: jhb >> >> Modified: >> head/sys/boot/efi/loader/main.c >> >> Modified: head/sys/boot/efi/loader/main.c >> ============================================================================== >> --- head/sys/boot/efi/loader/main.c Fri Oct 14 17:04:07 2016 (r307325) >> +++ head/sys/boot/efi/loader/main.c Fri Oct 14 17:10:53 2016 (r307326) >> @@ -235,6 +235,7 @@ main(int argc, CHAR16 *argv[]) >> uint64_t pool_guid; >> UINTN k; >> int has_kbd; >> + char buf[40]; >> >> archsw.arch_autoload = efi_autoload; >> archsw.arch_getdev = efi_getdev; >> @@ -447,6 +448,9 @@ main(int argc, CHAR16 *argv[]) >> for (k = 0; k < ST->NumberOfTableEntries; k++) { >> guid = &ST->ConfigurationTable[k].VendorGuid; >> if (!memcmp(guid, &smbios, sizeof(EFI_GUID))) { >> + snprintf(buf, sizeof(buf), "%p", >> + ST->ConfigurationTable[k].VendorTable); >> + setenv("hint.smbios.0.mem", buf, 1); >> smbios_detect(ST->ConfigurationTable[k].VendorTable); >> break; >> } >> @@ -603,7 +607,8 @@ command_configuration(int argc, char *ar >> else if (!memcmp(guid, &acpi20, sizeof(EFI_GUID))) >> printf("ACPI 2.0 Table"); >> else if (!memcmp(guid, &smbios, sizeof(EFI_GUID))) >> - printf("SMBIOS Table"); >> + printf("SMBIOS Table %p", >> + ST->ConfigurationTable[i].VendorTable); >> else if (!memcmp(guid, &dxe, sizeof(EFI_GUID))) >> printf("DXE Table"); >> else if (!memcmp(guid, &hoblist, sizeof(EFI_GUID))) >>