From nobody Thu Feb 16 08:28:38 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 4PHSlD6hb3z3pMS1 for ; Thu, 16 Feb 2023 08:28:40 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PHSlD6Dtrz3P6M; Thu, 16 Feb 2023 08:28:40 +0000 (UTC) (envelope-from gbe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676536120; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hsq9ofFUSrv430Ij/f/gUK2OoDYJNI9tiERHkDtAVA8=; b=sX1cseRVv/DlGf+ZUw93svozt/3OimZE2DIPYmEI2W5UlxCBrbqcNhOG+fBNghbZdgGTwO NH027+Z9pjL8RLEWP2FLuJCJLHwIp5RdmAM8XKawjAMQrDn5oIFcgvudM0vaDwwRH2GEZL hxqy8fuwkqMSgbLY629KlX81m/aPnyAaDblA76CeUH5lir3vJas41Bu6FIa6AQhqJEAcL9 VTPXPq/qIsJjEpKlCMJCOFg6lRfy/ImEbgCDpBqJuOabzesOSSRW6+Tp/+2TaMPpYLVU7E Vh+kT74O1KWklnnYfudSYKMPEeNrmo9H9Ws2jhOChfgXqyG5he0oAOwua08UzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676536120; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hsq9ofFUSrv430Ij/f/gUK2OoDYJNI9tiERHkDtAVA8=; b=yu7cstBE3dVPZyUPpxoRQkF3XuwMVhb0peohP2E2cJsOLJRxafo4fbivE3EXV2lYYWC1Gp uuvO4bzF9HPQY9m/V6Sb7xZ0GQwohTxPbUA3kzyc3cIoTW5i0y9qgZNK0JabpNkZ+t+2LJ yVjIwtXjgTIoeLjoI6HMNeVjcG3vScC0e/7pESqUEoDG56XEZcd9RBktB2stijW8sC5jt2 JYu3YcE5T2C8NOHcbBVVqXS4TS22MJcclhstyRpW2YsArAXJciQV2Yzt61trYcUacMTBFm laSqZ/Sw2enjL3KmF0maiYzFGGkl5mmsj1YS8w5oO8rQdNHLX9jCcBUwNUsOEA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1676536120; a=rsa-sha256; cv=none; b=qoup4usS2yscAaajxnhYXVEj7vKYsJFS6v0WtUL6As8C5eNN95Ab7Z9RTOc7WKlHeCt+WG DsDHvt/lpXU3Ve2MREfEGKvoBostuzOKvj8Q5SakT8v+3ZmgwoHEsp0rD7q77Ri/URWQgc eVhw6Kl/7KYh/nPVKCKBkiaPmyOCoV+wJdq9zQdtOrrK9vIul/2xdrnVZpkCcx2m8W+tZb I3N6xvyMx82kXTFsLsrN07IRWZQtDdQHn0RFy0buwrXA+ocDL/A3tbV4GIHHveGKAmDkln kQEEsEHdEoVW/YHrHCHWTuMIx4CcqxFLhVTMx/VekTuovyWQWpNATnG9HpP/RA== Received: from localhost (p200300cb871a694eb5fedb6a75c132cd.dip0.t-ipconnect.de [IPv6:2003:cb:871a:694e:b5fe:db6a:75c1:32cd]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: gbe) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PHSlD2Zw3z1RLL; Thu, 16 Feb 2023 08:28:40 +0000 (UTC) (envelope-from gbe@freebsd.org) Date: Thu, 16 Feb 2023 09:28:38 +0100 From: Gordon Bergling To: Colin Percival Cc: freebsd-arch@freebsd.org Subject: Re: RFC: Removing WITHOUT_CAPSICUM and WITHOUT_CASPER from 14.x Message-ID: References: <01000186589237d9-6c480554-3d01-405a-9f7a-81e96ae2a395-000000@email.amazonses.com> 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 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="muXi3RvwTHNSc94g" Content-Disposition: inline In-Reply-To: <01000186589237d9-6c480554-3d01-405a-9f7a-81e96ae2a395-000000@email.amazonses.com> X-Url: X-Operating-System: FreeBSD 13.2-STABLE amd64 X-Host-Uptime: 9:25AM up 15:46, 2 users, load averages: 0.47, 0.33, 0.26 X-ThisMailContainsUnwantedMimeParts: N --muXi3RvwTHNSc94g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Colin, On Thu, Feb 16, 2023 at 04:53:43AM +0000, Colin Percival wrote: > Hi FreeBSD architects, >=20 > I'd like to remove WITHOUT_CAPSICUM and WITHOUT_CASPER for FreeBSD 14.x. >=20 > The rationale for this is threefold: >=20 > 1. They doesn't serve any useful purpose and merely weakens security; >=20 > 2. They're an anomaly among WITH/WITHOUT options -- most WITHOUT_* options > take the form "don't build/install " rather than having > effects across the entire tree. >=20 > 3. They're a pain for release engineering, because approximately nobody e= ver > tests FreeBSD with WITHOUT_CAPSICUM or WITHOUT_CASPER set, but they're the > sort of option which can easily break the build due to having affects all > over the tree. >=20 > If nobody objects, my plan is to get rid of the WITHOUT_ build options fi= rst > and leave MK_{CAPSICUM,CASPER} set unconditionally to "yes"; then sweep t= he > tree (mostly a matter of running unifdef) after 14.x is branched. I would think that this a good idea, besides from the release engineering p= oint of view I can't think about a business case where security measures should = be disabled. --Gordon --muXi3RvwTHNSc94g Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEYbWI0KY5X7yH/Fy4OQX2V8rP09wFAmPt6SxfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYx QjU4OEQwQTYzOTVGQkM4N0ZDNUNCODM5MDVGNjU3Q0FDRkQzREMACgkQOQX2V8rP 09x8HggAtS99Oxwq+aJc7xbyFWPR12QaSzNU+ZHj0XcE/+pcsSP838lzjYJovlhO 36lRTz973HHfpNaoRc/gWADWiyNrqRxoqKBUvBK36UmwBLlpW5I65yaoXlIwg4HC JoRmGs8EqPV6+ENcfmc+G2ueoKFeBN/D3o0+OairSaYpqZ9ram9ezeghnowE0Db2 XYdUb2BhGqdyzZdapKfUFGLNmrVJmRVj4ibm1Cs4il+H/MZjfTV+F5HQjPJuYOzG hYt3juaLXuagwH6nqshmOz7nNmSu6cMcNFrZTpRwFqopwy13tkwLReLk9vH+j3iE gIgGrPAZdVdwCSEd5e5C83024KNcQQ== =HqYv -----END PGP SIGNATURE----- --muXi3RvwTHNSc94g-- From nobody Mon Feb 20 20:12:33 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 4PLD9s2spwz3s6lB for ; Mon, 20 Feb 2023 20:12:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 4PLD9r23Dkz3K2X for ; Mon, 20 Feb 2023 20:12:48 +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=8EzkqM4v; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::529) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x529.google.com with SMTP id ec43so8466212edb.8 for ; Mon, 20 Feb 2023 12:12:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kopteQJfHyYUMAaXEZ8Q2ehGoEPFOsFstfTH4EeTDL0=; b=8EzkqM4vz4+hKGx3h7QRNTHumRQ/COHJcA11xZglyGeuJyxdnCbCdffM2+tJuo4s2f kbnx/IYmZWTm2k+bQEo+2xEdzsK4KNm8iyohrZttVg/kQpbxFFnf/sgwEqkIQVshb6bP TMBjb0Icrt8W4zwaYBbPLjmyVyzDH4iiUyV+auj1khZ0EMn+wejsPyMHV9WNet1Wo8Vd tGPK+C5Y5kq4vWGENz1LPi+G6ukh2i2e9FjWGwC9nTtsrnA/ET+qGKgJ5/e8fJ7ZED9d fOb21rDSFSA2mlXkWwAuXl1/njlRONO/A7UvKHgyWokNnHzCt/4NdKWzL8P7QGwodFc4 O8rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc: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=kopteQJfHyYUMAaXEZ8Q2ehGoEPFOsFstfTH4EeTDL0=; b=Pe4hPtGj5DxYVTzmM+mmBMn5UAyxsSc6mvL7sM8IEckAsy2JnXvoLtA0RoBmjM29Zu io4L4r1+WFzQFkcmrTU8ceV5Fw5NjMLjaInrjPOgOq1/6TETJAafEHckCn7IPtyazkDg cdPfPpOtJCljUO9vwk4gpNgBX4iWtA/bvI0TfZT7qXsC7WNbkwUmqI2miqD/QolukblF SFPBXBJAG+i028Z9bHGCOhWmtBUZGARXqK46wilsNUUe+1+EXDCgToyP1yp+fbsx219h dktfCunN3vNRvHCp2Jnubq0rNDuyRkeMSXNYS93cfZnFl0XkCh8Mag/5zpfYNrtXFLcA Mysw== X-Gm-Message-State: AO0yUKUkOWcMpr0SLQjs6BcBPINhJe/fRaqxWs+jhVLOq+mY4ek2r0Nw mn3l8ln8GZsKyTEwknCHC55Vkn4gfTvqEeIyFomRPQ== X-Google-Smtp-Source: AK7set8YlzCBAlSpRgg2gsomjFgotEj+fQyzlx1a4huobdq8j2OeYAhBu5Ctv+Rlhw+XBt7pnYzpDBXYy/RQWVxKQvw= X-Received: by 2002:a05:6402:3216:b0:4ad:7bb2:eefb with SMTP id g22-20020a056402321600b004ad7bb2eefbmr854951eda.3.1676923964635; Mon, 20 Feb 2023 12:12:44 -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: <01000186589237d9-6c480554-3d01-405a-9f7a-81e96ae2a395-000000@email.amazonses.com> In-Reply-To: <01000186589237d9-6c480554-3d01-405a-9f7a-81e96ae2a395-000000@email.amazonses.com> From: Warner Losh Date: Mon, 20 Feb 2023 13:12:33 -0700 Message-ID: Subject: Re: RFC: Removing WITHOUT_CAPSICUM and WITHOUT_CASPER from 14.x To: Colin Percival Cc: freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003a4edf05f527495d" X-Spamd-Result: default: False [-2.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.968]; 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]; 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:~]; RCVD_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-Rspamd-Queue-Id: 4PLD9r23Dkz3K2X X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --0000000000003a4edf05f527495d Content-Type: text/plain; charset="UTF-8" My only feedback is that bsd-user doesn't fully implement capsicum, which may cause issues with that... Warner On Wed, Feb 15, 2023 at 9:53 PM Colin Percival wrote: > Hi FreeBSD architects, > > I'd like to remove WITHOUT_CAPSICUM and WITHOUT_CASPER for FreeBSD 14.x. > > The rationale for this is threefold: > > 1. They doesn't serve any useful purpose and merely weakens security; > > 2. They're an anomaly among WITH/WITHOUT options -- most WITHOUT_* options > take the form "don't build/install " rather than having > effects across the entire tree. > > 3. They're a pain for release engineering, because approximately nobody > ever > tests FreeBSD with WITHOUT_CAPSICUM or WITHOUT_CASPER set, but they're the > sort of option which can easily break the build due to having affects all > over the tree. > > If nobody objects, my plan is to get rid of the WITHOUT_ build options > first > and leave MK_{CAPSICUM,CASPER} set unconditionally to "yes"; then sweep the > tree (mostly a matter of running unifdef) after 14.x is branched. > > -- > Colin Percival > FreeBSD Deputy Release Engineer & EC2 platform maintainer > Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid > > --0000000000003a4edf05f527495d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My only feedback is that bsd-user doesn't fully implem= ent capsicum, which may cause
issues with that...

<= div>Warner

On Wed, Feb 15, 2023 at 9:53 PM Colin Percival <cperciva@tarsnap.com> wrote:
Hi FreeBSD architects,=

I'd like to remove WITHOUT_CAPSICUM and WITHOUT_CASPER for FreeBSD 14.x= .

The rationale for this is threefold:

1. They doesn't serve any useful purpose and merely weakens security;
2. They're an anomaly among WITH/WITHOUT options -- most WITHOUT_* opti= ons
take the form "don't build/install <components>" rather= than having
effects across the entire tree.

3. They're a pain for release engineering, because approximately nobody= ever
tests FreeBSD with WITHOUT_CAPSICUM or WITHOUT_CASPER set, but they're = the
sort of option which can easily break the build due to having affects all over the tree.

If nobody objects, my plan is to get rid of the WITHOUT_ build options firs= t
and leave MK_{CAPSICUM,CASPER} set unconditionally to "yes"; then= sweep the
tree (mostly a matter of running unifdef) after 14.x is branched.

--
Colin Percival
FreeBSD Deputy Release Engineer & EC2 platform maintainer
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid=

--0000000000003a4edf05f527495d-- From nobody Wed Feb 22 04:05:56 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 4PM2dT3Kdvz3sCvx for ; Wed, 22 Feb 2023 04:06:05 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gold.funkthat.com [IPv6:2001:470:800b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PM2dS1xszz3sX0 for ; Wed, 22 Feb 2023 04:06:04 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 2001:470:800b::2) smtp.mailfrom=jmg@gold.funkthat.com; dmarc=none Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 31M45ua6079291 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 21 Feb 2023 20:05:56 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 31M45uL3079290 for freebsd-arch@FreeBSD.org; Tue, 21 Feb 2023 20:05:56 -0800 (PST) (envelope-from jmg) Date: Tue, 21 Feb 2023 20:05:56 -0800 From: John-Mark Gurney To: freebsd-arch@FreeBSD.org Subject: making identify_hypervisor arch independent Message-ID: <20230222040556.GP95670@funkthat.com> Mail-Followup-To: freebsd-arch@FreeBSD.org 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Tue, 21 Feb 2023 20:05:56 -0800 (PST) X-Spamd-Result: default: False [-1.80 / 15.00]; AUTH_NA(1.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)[jmg@funkthat.com,jmg@gold.funkthat.com]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@FreeBSD.org]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[funkthat.com]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[jmg]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PM2dS1xszz3sX0 X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N 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 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). Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." 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-- From nobody Wed Feb 22 07:10:52 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 4PM6kp3ggGz3sflW for ; Wed, 22 Feb 2023 07:10:58 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PM6kp3FwSz49pr; Wed, 22 Feb 2023 07:10:58 +0000 (UTC) (envelope-from rpokala@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1677049858; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4woJk8tjL8rLNwCAKm+zZ2yPp+HBFW8K/j/70ERTo+8=; b=FhkGI9aEqecvxT/YU3J8+ZgxDhIrx3lncwsBS46klo/zfZh9ZE/PBa7x6Gb4l0yBIOIJtI PIFZ/2pF032FRrznNjyBL6713h5dzk8fWsX+kBwVzmOwSCTx+TNV6Wlyqr0gdpGLe79lbw Gjwysec0bdoNKgTccIWyaAI5x7cH4OjNzS87wurb2VsGLxJxVBOGUtknNNXOZpy+ezgZPL N1JeI1FSUTn2jZ20qJmyU2DlMsMtD0kVlm9Hov3UYwi0sHiqxG1oFFuOJeSRnyI+jWxtbj v+L9Qry6MImxWJW4lqvx8hCQXKmi62UET/0h8aDaflfGhjIU0M6ogSW5Nb2fQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1677049858; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4woJk8tjL8rLNwCAKm+zZ2yPp+HBFW8K/j/70ERTo+8=; b=osS1ei+zBbGJo6gDeDH02SF0Apajpt7/cCJUdVUSblPh0upguJijJ5pURxM+SkWaXB0tRO 4hS4EYZaNE2Epdtf3n9CwLRwY3LRMQjD+Mg4vIj5e5ySHt/7TwayagCtRTiWVmKSAJeCFV PguBo27qYMHwHl3V3KvWXu65n3mTNlNzwPc81n8mjP65He9JZbCfJS4J9C8v9iojkQEzgR c5PHTsMzvn9E3zatOiytzelMUps8wllqPu2cki7Sm89Et1yND2IO38/qtEIMRLoUEp/cWg LnBnf4jqsc9XmbOmGhuRDn4lus1w9X0sNtKzn5KoFJqiVqnzu3nxdL7DwSWkfQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1677049858; a=rsa-sha256; cv=none; b=ovVBqQ6txKwYEVIJ0LdsPbmK0wLOR6enTgTeiPIEOR0l3cZglsu4hvB2anHQDHbtb2Hiun Z2eHjrWHMgTatdJc2QCItkUE/8qX92N0ig/RFdAhUxoOPupveJJ/nnKkSSkBzqChfKuhbX jArUmI6XnJJ1/6Pz30Rt5ynm848slWcB5Qh/ECDHDo+m4ZvzVOVBabwW+DdFzn7Hh26Y2r 7TEwoCfOZhn4zwqxpWwPs3iZl05GCs79sjDTRgsn59exh6H713vnxZTM8z/TWgNrcUtMPQ dDjHHucfiVkaHc0oaDZCy+/4X0U2QJ1KfGz436TbB0fUVW4wX7l4MxQmOZJq4Q== Received: from [192.168.1.10] (unknown [98.42.164.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: rpokala) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PM6kn6J76ztsp; Wed, 22 Feb 2023 07:10:57 +0000 (UTC) (envelope-from rpokala@freebsd.org) User-Agent: Microsoft-MacOutlook/16.70.23021201 Date: Tue, 21 Feb 2023 23:10:52 -0800 Subject: Re: making identify_hypervisor arch independent From: Ravi Pokala To: John-Mark Gurney , , Doug Ambrisko Message-ID: <01C4EB39-8218-47CE-8413-D4E5A395AD39@panasas.com> Thread-Topic: making identify_hypervisor arch independent References: <20230222040556.GP95670@funkthat.com> In-Reply-To: <20230222040556.GP95670@funkthat.com> 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 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-ThisMailContainsUnwantedMimeParts: N > I briefly thought of dev/smbios, BUT, that brings up another issue, I thi= nk we should deorbit dev/smbios, and move smbios.h to dev/ipmi, because as f= ar 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 tab= le. Once upon a time, Panasas had a much more involved smbios(4). It parsed out= a bunch of the same SMBIOS strings as the loaders do, but also decoded a bu= nch of information about the DIMMs (Table 17) and exposed them via sysctls. = However, when we subsequently rebased onto a more modern version of FreeBSD,= expediency came down on the side of screen-scraping `dmidecode' output in a= script, and having userland tools exec that rather than reading sysctls. At one point, ambrisko@ and I had talked about moving generic smbios-walkin= g code into smbios(4), exposing that to the kernel through an smbios_if.m, t= hen things like ipmi(4) could leverage that. (And, for example, if a driver = wanted to be able to map between physical address and DIMM, it could use tha= t interface to find Table 17, Table 19, Table 20, etc.) Alas, neither of us = has had the time to work on that. In a later message in this thread, Warner suggested consolidating that code= into subr_smbios.c rather than smbios(4). I think that would be functionall= y equivalent. Thanks, Ravi =EF=BB=BF-----Original Message----- From: > on behalf of John-Mark Gurney > Date: 2023-02-21, Tuesday at 20:05 To: > Subject: making identify_hypervisor arch independent 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=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? kern/subr_identsmbios.c? And make it optional on EFIRT for arm64 and standard on x86? 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). Thanks. --=20 John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Wed Feb 22 10:44:11 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 4PMCT26llfz3srQq for ; Wed, 22 Feb 2023 10:44:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PMCT21QJfz4Q0q for ; Wed, 22 Feb 2023 10:44:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.17.1/8.17.1) with ESMTPS id 31MAiBuo045997 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 22 Feb 2023 12:44:15 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 31MAiBuo045997 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 31MAiB21045996; Wed, 22 Feb 2023 12:44:11 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 22 Feb 2023 12:44:11 +0200 From: Konstantin Belousov To: Warner Losh Cc: freebsd-arch@freebsd.org Subject: Re: making identify_hypervisor arch independent Message-ID: References: <20230222040556.GP95670@funkthat.com> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4PMCT21QJfz4Q0q X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N 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? 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." > > > > From nobody Thu Feb 23 00:29:40 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 4PMYnP1wMSz3sfhH for ; Thu, 23 Feb 2023 00:29:45 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gold.funkthat.com [IPv6:2001:470:800b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PMYnN5K6zz3y5y for ; Thu, 23 Feb 2023 00:29:44 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Authentication-Results: mx1.freebsd.org; none Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 31N0Tf5Y062811 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Feb 2023 16:29:41 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 31N0TeSr062809; Wed, 22 Feb 2023 16:29:40 -0800 (PST) (envelope-from jmg) Date: Wed, 22 Feb 2023 16:29:40 -0800 From: John-Mark Gurney To: Konstantin Belousov Cc: Warner Losh , freebsd-arch@freebsd.org Subject: Re: making identify_hypervisor arch independent Message-ID: <20230223002940.GS95670@funkthat.com> Mail-Followup-To: Konstantin Belousov , Warner Losh , freebsd-arch@freebsd.org References: <20230222040556.GP95670@funkthat.com> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Wed, 22 Feb 2023 16:29:41 -0800 (PST) X-Rspamd-Queue-Id: 4PMYnN5K6zz3y5y X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N 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. > We do not put hardware-specific stuff in generic kernel sources' directory. Then where do/should we put cross platform (in this case, at least amd64 and arm64), non-device files? The code needs to be called before devices are probed. > > > 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... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Thu Feb 23 04:53:30 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 4PMgf35VZmz3syG0 for ; Thu, 23 Feb 2023 04:53:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PMgf13thKz4VTG for ; Thu, 23 Feb 2023 04:53:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.17.1/8.17.1) with ESMTPS id 31N4rUnX018230 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 23 Feb 2023 06:53:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 31N4rUnX018230 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 31N4rULg018228; Thu, 23 Feb 2023 06:53:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 23 Feb 2023 06:53:30 +0200 From: Konstantin Belousov To: Warner Losh , freebsd-arch@freebsd.org Subject: Re: making identify_hypervisor arch independent Message-ID: References: <20230222040556.GP95670@funkthat.com> <20230223002940.GS95670@funkthat.com> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230223002940.GS95670@funkthat.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Result: default: False [-2.86 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.86)[-0.864]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; R_SPF_SOFTFAIL(0.00)[~all]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; HAS_XAW(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4PMgf13thKz4VTG X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N 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. In fact, there is even stuff like dev/{xz,zlib}. > > > We do not put hardware-specific stuff in generic kernel sources' directory. > > Then where do/should we put cross platform (in this case, at least amd64 and > arm64), non-device files? The code needs to be called before devices > are probed. > > > > > 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... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." From nobody Fri Feb 24 05:27:58 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 4PNJMF0Tl6z3tHXr for ; Fri, 24 Feb 2023 05:28:09 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gold.funkthat.com [IPv6:2001:470:800b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PNJMD0x2Kz4XBQ for ; Fri, 24 Feb 2023 05:28:07 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 2001:470:800b::2) smtp.mailfrom=jmg@gold.funkthat.com; dmarc=none Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 31O5RwnU012075 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Feb 2023 21:27:59 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 31O5Rwvi012073; Thu, 23 Feb 2023 21:27:58 -0800 (PST) (envelope-from jmg) Date: Thu, 23 Feb 2023 21:27:58 -0800 From: John-Mark Gurney To: Konstantin Belousov Cc: Warner Losh , freebsd-arch@freebsd.org Subject: Re: making identify_hypervisor arch independent Message-ID: <20230224052758.GT95670@funkthat.com> Mail-Followup-To: Konstantin Belousov , Warner Losh , freebsd-arch@freebsd.org References: <20230222040556.GP95670@funkthat.com> <20230223002940.GS95670@funkthat.com> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Thu, 23 Feb 2023 21:27:59 -0800 (PST) X-Spamd-Result: default: False [-1.80 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; MIME_GOOD(-0.10)[text/plain]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEFALL_USER(0.00)[jmg]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[funkthat.com]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PNJMD0x2Kz4XBQ X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N 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... > 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. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." 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--