Re: making identify_hypervisor arch independent

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?

We do not put hardware-specific stuff in generic kernel sources' directory.

> 
> 
> > 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...
> 
> Warner
> 
> Warner
> 
> 
> > Thanks.
> >
> > --
> >   John-Mark Gurney                              Voice: +1 415 225 5579
> >
> >      "All that I will do, has been done, All that I have, has not."
> >
> >