Re: making identify_hypervisor arch independent
- In reply to: John-Mark Gurney : "Re: making identify_hypervisor arch independent"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 24 Feb 2023 06:38:03 UTC
On Thu, Feb 23, 2023 at 10:28 PM John-Mark Gurney <jmg@funkthat.com> 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 <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. > > 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." >