From nobody Fri Feb 24 06:38:03 2023 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PNKw62vCLz3tbPs for ; Fri, 24 Feb 2023 06:38:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PNKw55152z4cWD for ; Fri, 24 Feb 2023 06:38:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=tvf9xEtp; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::533) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x533.google.com with SMTP id eg37so47149931edb.12 for ; Thu, 23 Feb 2023 22:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=RGX2V1ek8fJd6jGtp2VKiHHp/w94RYL1aSI+3O6FkOE=; b=tvf9xEtp7w+uESZA+seRpE5vZgL4+TaRr4ES/cuHf6QEHXOat7PCmZQrqXLX7FcuCt rp2Tbh8vLvULRS5ooSntxbe1/sJ1yf7fiIL155Kkw2A/GcIux+NFYZpElPSd20Ekd0kC cFbzVa7HwbCrzjOXz+AJv6W4yPXJa/s2VhSSSsoYo4s0mMaoGyhR8MTnmZI3GTXneZXm T5sr1NzIGT+3qh1rHqQ5rhRtGNb2IWJkUClcZC1m10p/MOKliJOg58oqA5mGCKNamixR lVF1MjIprd2Th7IpWGcBvFlnCGpHNkbcE62+RKF3sMo8ahhWKDlJaSqVTeRIKsvsgf66 CP5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RGX2V1ek8fJd6jGtp2VKiHHp/w94RYL1aSI+3O6FkOE=; b=oBtsn2gHHCriIBRSFi8aJUKVtP1F8glKJ071sf/QQ4G9ueqg9ZP10w3ibUyQiWjpCa 0qigy2eWLCXLP6QaL+G4Xv9sDi+ZBXEhgSR5DjCty6BsDWNWhxWRo2YXUhZmXfPg+BBx KeoZhu3eOiHhJIywOO6skDzXO9hTu6QzzDNBjblBzHK0fvR7StaQwz2jGRgAF7xE3bWJ qg4x26BEeQojAmuqduPzPfy1eTUvxwbKI2faK6xqpk0Rjmo/v+WiBVg8ZSlWX5ftgxXA op4xn+YXVeyGspIHqDqjNkNCO2IgKCCnFJS6I3y/ZH3h+y7EjXzPrhgKcff4SJrtLj7V dthg== X-Gm-Message-State: AO0yUKUNZ2HCQlMM5o7j0slipz1qQh9QfTUeKkOvC0AgloxCCaKVEq+9 PyuT05y0WCYANgiqyoiDwfYUeGYOLz0iK0jmvZ+0Kw== X-Google-Smtp-Source: AK7set9FF5u39W6TpOc9ksWnRvEymDedV0FcXvUCB2luGTC7IDOeSZelYhloGskJxs8k6X5a3rBPjD4/GQwtx6XR13Q= X-Received: by 2002:a50:d517:0:b0:4ad:5274:dbee with SMTP id u23-20020a50d517000000b004ad5274dbeemr6649611edi.0.1677220691718; Thu, 23 Feb 2023 22:38:11 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <20230222040556.GP95670@funkthat.com> <20230223002940.GS95670@funkthat.com> <20230224052758.GT95670@funkthat.com> In-Reply-To: <20230224052758.GT95670@funkthat.com> From: Warner Losh Date: Thu, 23 Feb 2023 23:38:03 -0700 Message-ID: Subject: Re: making identify_hypervisor arch independent To: Konstantin Belousov , Warner Losh , freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="0000000000008a474505f56c5f03" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_TO(0.00)[gmail.com,bsdimp.com,freebsd.org]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4PNKw55152z4cWD X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --0000000000008a474505f56c5f03 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 23, 2023 at 10:28 PM John-Mark Gurney 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 > 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." > --0000000000008a474505f56c5f03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 23, 2023 at 10:28 PM John= -Mark Gurney <jmg@funkthat.com&g= t; wrote:
Konsta= ntin 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.fr= eebsd.org/D38721) that will make
> > > > > SMBIOS work on arm64 systems (specifically under q= emu, 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 run= ning as a guest under
> > > > > QEMU so that we automatically switch to hz=3D100 o= n arm64.
> > > > >
> > > > > Currently there is code in x86/x86/identcpu.c that= has code to identify
> > > > > hypervisers via SMBIOS, so I'd like to move mo= st of identify_hypervisor
> > > > > to a new location so that arm64 code can call it a= s well.
> > > > >
> > > > > Where should I put it?=C2=A0 kern/subr_identsmbios= .c?=C2=A0 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 ba= sically required for
> > > > arm64. It's not dependent at all on efi run time su= pport.
> > > 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.=C2=A0 = 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= 9;s called well
in advance of the bus probe / attach and that cod= e lives in dev/acpica.
Earlier in the thread I think I steered yo= u wrong...
=C2=A0
> 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 in= dependent code... It's more subtle than that...
It's for = arch independent code that implements an arch independent
specifi= cation.

=C2=A0
--
=C2=A0 John-Mark Gurney=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Voice: +1 415 225 5579=

=C2=A0 =C2=A0 =C2=A0"All that I will do, has been done, All that I hav= e, has not."
--0000000000008a474505f56c5f03--