From nobody Wed Feb 22 05:22:41 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 4PM4L65XjQz3sJ8x for ; Wed, 22 Feb 2023 05:22:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 4PM4L54RC9z41QN for ; Wed, 22 Feb 2023 05:22:53 +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=NOoeHuZ7; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::530) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x530.google.com with SMTP id da10so27009648edb.3 for ; Tue, 21 Feb 2023 21:22:53 -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=GQ7iHstWWzE6uvpCfNfpqMVl44cAFzLP8QgjK1DM0Pc=; b=NOoeHuZ7elLoO49WZgU7u/fJE8MhNcj9oPR24hkWSITItcnF8Kvn5RFZPLoGI1QAoq qbNq+BCZy83OLfIVrgOHEhFKJ8il20PG0Tobgk8ql++UF6VV4TE5pzpRuz+mcYPhkJ1V 2vQr7fxu3UbKfAKXDUcdm6ezMHwOrNGDbvymzWKQmWce1cyRRl0gtWsd6XmRwAZ/GbSV RMYAM8cxQFWGHVX1MWBZZ7mPFbTqsuLICyyOlvcR02VZ5wJ++3u0WrmgjFZQN0u1Avmm QiJCry4fXjKB+pgcsdA1TWeG/jFsEzJ7+3b77gs31xSpNFNouv8vw1Q6jB0JtyCo4Eu/ 8BJg== 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=GQ7iHstWWzE6uvpCfNfpqMVl44cAFzLP8QgjK1DM0Pc=; b=4mZiiLlVqSTXWFBdQK6A6aVMrz8D9PJ/OfcebPu65GF3X4sxe1bSfWsEPHlQoiEiSJ yrT2NykY2gR4qX+BLeKsCNqogHKC4FeMaeNOWx3DXfKr7eMubM0isoFImFmTcr/ShDQg VVstPxMULNkBmqA1gjSJ/fMagXwPqsy040hAFNdxRgvxPJHlDNkOwyrXbVgksTuylrPY jAB92zByiOEL33hDSvn1SUdsME2GX4IO4D4HDvwmmidDVqAE4cEjuZeVRYqg9ZpDfP5O 0t4iiF3ix3o506kXs+7KBMGSCqKXpdtR51n9VoKoZ9Wc0p2BC0wYbPBNJ/ygmYPuRXRo ILkw== X-Gm-Message-State: AO0yUKUi/hHeKKvH2waXwmTgKEEKnKwEpgPrN+duq+dfNXuAcMrw2S0i ye7TQm5uMsJl83KipthTjPaBCBj/kYGt2LJdbABwobQNUNMjYg== X-Google-Smtp-Source: AK7set96LAWF+kzz7+joxdVrYPbA17zIpppGNiYYwnMaEQau0+lfFhdh/RB6nFR4gqiqzUSx3zSjk67rm8Vb/mr9M5I= X-Received: by 2002:a50:bae3:0:b0:4a8:2436:4ed2 with SMTP id x90-20020a50bae3000000b004a824364ed2mr2928286ede.0.1677043371975; Tue, 21 Feb 2023 21:22:51 -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> In-Reply-To: <20230222040556.GP95670@funkthat.com> From: Warner Losh Date: Tue, 21 Feb 2023 22:22:41 -0700 Message-ID: Subject: Re: making identify_hypervisor arch independent To: freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="00000000000075ba5005f5431660" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; 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]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4PM4L54RC9z41QN X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --00000000000075ba5005f5431660 Content-Type: text/plain; charset="UTF-8" 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. > 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." > > --00000000000075ba5005f5431660 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 21, 2023 at 9:06 PM John-= Mark Gurney <jmg@funkthat.com>= ; wrote:
Hello,<= br>
I have a pending diff (https://reviews.freebsd.org/D38721) t= hat 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=3D100 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?=C2=A0 kern/subr_identsmbios.c?=C2=A0 And make it opt= ional
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.
=C2= =A0
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.=C2=A0 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.=C2=A0 Th= e
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 t= empted
to make those into wrappers to make it harder to misspell = the string they
all pass in...=C2=A0 Even if it's just a wrap= per around kenv_getenv with the
right string... They are mostly u= sed for 'quirks'.

Either way, I think sys/= dev/smbios likely has limited value...=C2=A0 It would be
differen= t if it provided some way to get the raw smbios table... But as
i= t is, I think all programs that parse it get it via /dev/mem...

Warner

Warner
=C2=A0
Thanks.

--
=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."

--00000000000075ba5005f5431660--