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