Date: Wed, 22 Feb 2023 16:29:40 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Warner Losh <imp@bsdimp.com>, freebsd-arch@freebsd.org Subject: Re: making identify_hypervisor arch independent Message-ID: <20230223002940.GS95670@funkthat.com> In-Reply-To: <Y/Xx%2B5YqhS8TuekK@kib.kiev.ua> References: <20230222040556.GP95670@funkthat.com> <CANCZdfox_xLs9c%2BmxPriWQ7qymiF%2BNHqNHk_TEtvswswav2oYg@mail.gmail.com> <Y/Xx%2B5YqhS8TuekK@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Konstantin Belousov wrote this message on Wed, Feb 22, 2023 at 12:44 +0200: > On Tue, Feb 21, 2023 at 10:22:41PM -0700, Warner Losh wrote: > > On Tue, Feb 21, 2023 at 9:06 PM John-Mark Gurney <jmg@funkthat.com> wrote: > > > > > Hello, > > > > > > I have a pending diff (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=100 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'd do kern/subr_smbios.c. > > > > I'd be tempted to make it standard, since EFI is basically required for > > arm64. It's not dependent at all on efi run time support. > Why not extend existing sys/dev/smbios? Because it's not a device like dev says it should be. > We do not put hardware-specific stuff in generic kernel sources' directory. Then where do/should we put cross platform (in this case, at least amd64 and arm64), non-device files? The code needs to be called before devices are probed. > > > 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). > > > > > > > I'd be tempted to move all the smbios walking into subr_smbios.c. > > > > All the other smbios stuff does depend on the boot loader walking > > and parsing the table and setting that in the kenv... I'd almost be tempted > > to make those into wrappers to make it harder to misspell the string they > > all pass in... Even if it's just a wrapper around kenv_getenv with the > > right string... They are mostly used for 'quirks'. > > > > Either way, I think sys/dev/smbios likely has limited value... It would be > > different if it provided some way to get the raw smbios table... But as > > it is, I think all programs that parse it get it via /dev/mem... -- 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?20230223002940.GS95670>