From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) by mx.groups.io with SMTP id smtpd.web10.21517.1680171518854427720 for ; Thu, 30 Mar 2023 03:18:39 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: proxmox.com, ip: 94.136.29.106, mailfrom: f.ebner@proxmox.com) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 94401417D5; Thu, 30 Mar 2023 12:18:36 +0200 (CEST) Message-ID: <7a47bad8-5479-8a56-e41b-3fd6961d9673@proxmox.com> Date: Thu, 30 Mar 2023 12:18:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH v3 1/1] OvmfPkg/SmbiosPlatformDxe: use PcdFirmware* To: Gerd Hoffmann 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 References: <20221128054020.25531-1-kraxel@redhat.com> From: "Fiona Ebner" In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Am 30.03.23 um 10:53 schrieb Gerd Hoffmann: > 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. > Should the date string be "02/02/2022" rather than "2/2/2022" in that commit? I was wondering whether month or date comes first and found the following in ([0], section 7.1): > String number of the BIOS release date. > The date string, if supplied, is in either > mm/dd/yy or mm/dd/yyyy format. If the year > portion of the string is two digits, the year is > assumed to be 19yy. > NOTE: The mm/dd/yyyy format is required for > SMBIOS version 2.3 and later. > You can set those using > 'build --pcd PcdFirmwareVersionString="L${string}\\0" ...' > (same for the other pcds). I had already found the build option in the discussion of v1 of this patch, but now I'm wondering: is the "\\0" explicitly required? My build yesterday seemed to work without it, but I guess, I'll just add it to make sure. >>> 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/ > Thank you for the explanation! Best regards, Fiona [0]: https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.2.0.pdf