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