From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.20521.1680166399198103549 for ; Thu, 30 Mar 2023 01:53:19 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NHKThVeq; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680166398; 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=/1CV759TBBhQzQXq/zHG8DZludkuU5XToVQVG82dosQ=; b=NHKThVeqYqHwIe7pUA+s6gffOeuZpIw+d2H8PfW6Bg8wmZzL21XjgAQO557z/g8Aa9Rqsf NU5Tgcal5y3gcUKx/ClC6tHCUlTcx8dmP2YsUizs50skYYYxU0MZfLyt8I/JzCjfk/ebbk xU6Q4Vj9/Gqw/sSNwSaDDOtrcikPPOA= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-158-Tu3N4G8XMxW95pkts2FDPA-1; Thu, 30 Mar 2023 04:53:15 -0400 X-MC-Unique: Tu3N4G8XMxW95pkts2FDPA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6C2662817231; Thu, 30 Mar 2023 08:53:14 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.193.49]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E7B091121330; Thu, 30 Mar 2023 08:53:13 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id DB821180061B; Thu, 30 Mar 2023 10:53:11 +0200 (CEST) Date: Thu, 30 Mar 2023 10:53:11 +0200 From: "Gerd Hoffmann" To: Fiona Ebner Cc: devel@edk2.groups.io, Pawel Polawski , Anthony Perard , Jordan Justen , Jiewen Yao , Liming Gao , Julien Grall , Oliver Steffen , Jian J Wang , Ard Biesheuvel , dannf@debian.org, Thomas Lamprecht Subject: Re: [PATCH v3 1/1] OvmfPkg/SmbiosPlatformDxe: use PcdFirmware* Message-ID: References: <20221128054020.25531-1-kraxel@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Mar 30, 2023 at 10:04:02AM +0200, Fiona Ebner wrote: > Am 28.11.22 um 06:40 schrieb Gerd Hoffmann: > > Instead of using hard-coded strings ("0.0.0" for BiosVersion etc) > > which is mostly useless read the PCDs (PcdFirmwareVendor, > > PcdFirmwareVersionString and PcdFirmwareReleaseDateString) and > > build the string table dynamuically at runtime. > > > > Signed-off-by: Gerd Hoffmann > > --- > > .../SmbiosPlatformDxe/SmbiosPlatformDxe.inf | 6 + > > .../XenSmbiosPlatformDxe.inf | 9 +- > > OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c | 115 +++++++++++------- > > 3 files changed, 85 insertions(+), 45 deletions(-) > > > > Hi, > after this patch, certain SMBIOS values are different[2]. We got a > report that the different vendor causes issues with hardware keys[0]. > And, as I learned from the patch fixing it, the missing date can cause > issues with Windows[1]. See a0f9628705e3 ("OvmfPkg/SmbiosPlatformDxe: tweak fallback release date") for the windows issue. > I assume this will affect other downstream distributors too. Since we > base our packaging off Debian, I asked there for how to best handle it > and am now passing along the question I got in return: You can set those using 'build --pcd PcdFirmwareVersionString="L${string}\\0" ...' (same for the other pcds). We had a patch introducing a define for that to allow the slightly more convenient 'build -D FIRMWARE_VER="${string}" ...' but that was never merged. > > It'd be > > good to understand what upstream's intention was there - are they > > expecting each distributor to set our own values, and if so, is there > > a scheme we should follow? The intention is to allow setting version information to whatever makes sense for you. A hardcoded "0.0.0" version certainly isn't very useful when it comes to bug reporting etc. Fedora leaves vendor unchanged, sets release date to the commit date of the edk2-stableyyyymm stable tag the build is based on and version to the rpm package version, i.e. like this ... Handle 0x0000, DMI type 0, 26 bytes BIOS Information Vendor: EDK II Version: edk2-20230301gitf80f052277c8-1.test6.fc37 Release Date: 03/01/2023 [ ... ] ... which allows to easily identify the exact firmware build running. The one listed above happens to be this one: https://download.copr.fedorainfracloud.org/results/kraxel/edk2.testbuilds/fedora-37-x86_64/05727085-edk2/ HTH & take care, Gerd