Re: making identify_hypervisor arch independent

On Thu, Feb 23, 2023 at 10:28 PM John-Mark Gurney <[email protected]> wrote:

> Konstantin Belousov wrote this message on Thu, Feb 23, 2023 at 06:53 +0200:
> > On Wed, Feb 22, 2023 at 04:29:40PM -0800, John-Mark Gurney wrote:
> > > 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 <[email protected]>
> 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.
> > dev/ does not imply that code from there needs either cdev or newbus
> > attachment,it is for code that is to handle platform or device.  smbios
> > fits perfectly into this description.
> >
> > Biggest example is dev/efidev, with its efirt/efirtc stuff.
> > Second would be dev/smbios.
>
> smbios isn't a good example, just a FYI, it IS a device driver, and
> it doesn't do anything except reserve a resource...
>

I think what he's saying is that we should take a page from what
efi is doing, though and have the parsing routines in dev/smbios
as separate files. ACPI also has a lot of code that's called well
in advance of the bus probe / attach and that code lives in dev/acpica.
Earlier in the thread I think I steered you wrong...


> > In fact, there is even stuff like dev/{xz,zlib}.
>
> Ok, I was just going on what sys/README.md says, I'll update that to
> make it clear that it isn't just for device drivers, and is any arch
> independent code.
>

well, not any arch independent code... It's more subtle than that...
It's for arch independent code that implements an arch independent
specification.



> --
>   John-Mark Gurney                              Voice: +1 415 225 5579
>
>      "All that I will do, has been done, All that I have, has not."
>