Date: Tue, 21 Feb 2023 23:10:52 -0800 From: Ravi Pokala <rpokala@freebsd.org> To: John-Mark Gurney <jmg@funkthat.com>, <freebsd-arch@freebsd.org>, Doug Ambrisko <ambrisko@FreeBSD.org> Subject: Re: making identify_hypervisor arch independent Message-ID: <01C4EB39-8218-47CE-8413-D4E5A395AD39@panasas.com> In-Reply-To: <20230222040556.GP95670@funkthat.com> References: <20230222040556.GP95670@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I briefly thought of dev/smbios, BUT, that brings up another issue, I thi= nk we should deorbit dev/smbios, and move smbios.h to dev/ipmi, because as f= ar as I can tell, the device does nothing useful. It allocates the resource,= but nothing that I can find in the tree attempts to use/access the device, = and it doesn't expose any interface. The header is only used by dev/ipmi for= the structure, but not the device, as ipmi does it's own parsing of the tab= le. Once upon a time, Panasas had a much more involved smbios(4). It parsed out= a bunch of the same SMBIOS strings as the loaders do, but also decoded a bu= nch of information about the DIMMs (Table 17) and exposed them via sysctls. = However, when we subsequently rebased onto a more modern version of FreeBSD,= expediency came down on the side of screen-scraping `dmidecode' output in a= script, and having userland tools exec that rather than reading sysctls. At one point, ambrisko@ and I had talked about moving generic smbios-walkin= g code into smbios(4), exposing that to the kernel through an smbios_if.m, t= hen things like ipmi(4) could leverage that. (And, for example, if a driver = wanted to be able to map between physical address and DIMM, it could use tha= t interface to find Table 17, Table 19, Table 20, etc.) Alas, neither of us = has had the time to work on that. In a later message in this thread, Warner suggested consolidating that code= into subr_smbios.c rather than smbios(4). I think that would be functionall= y equivalent. Thanks, Ravi =EF=BB=BF-----Original Message----- From: <owner-freebsd-arch@freebsd.org <mailto:owner-freebsd-arch@freebsd.or= g>> on behalf of John-Mark Gurney <jmg@funkthat.com <mailto:jmg@funkthat.com= >> Date: 2023-02-21, Tuesday at 20:05 To: <freebsd-arch@FreeBSD.org <mailto:freebsd-arch@FreeBSD.org>> Subject: making identify_hypervisor arch independent Hello, I have a pending diff (https://reviews.freebsd.org/D38721 <https://reviews.= freebsd.org/D38721>) that will make SMBIOS work on arm64 systems (specifically under qemu, but likely it may add support for other EFI arm64 systems that have SMBIOS as well). The goal is to support identifying that we are running as a guest under QEMU so that we automatically switch to hz=3D100 on arm64. Currently there is code in x86/x86/identcpu.c that has code to identify hypervisers via SMBIOS, so I'd like to move most of identify_hypervisor to a new location so that arm64 code can call it as well. Where should I put it? kern/subr_identsmbios.c? And make it optional on EFIRT for arm64 and standard on x86? I briefly thought of dev/smbios, BUT, that brings up another issue, I think we should deorbit dev/smbios, and move smbios.h to dev/ipmi, because as far as I can tell, the device does nothing useful. It allocates the resource, but nothing that I can find in the tree attempts to use/access the device, and it doesn't expose any interface. The header is only used by dev/ipmi for the structure, but not the device, as ipmi does it's own parsing of the table. All of the uses of smbios data is getting it via kenv which is populated via loader (libsa). Thanks. --=20 John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01C4EB39-8218-47CE-8413-D4E5A395AD39>