Re: [PATCH v3 1/1] OvmfPkg/SmbiosPlatformDxe: use PcdFirmware*

["Fiona Ebner" <f.ebner@proxmox.com>]

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 <kraxel@redhat.com>
>>> ---
>>>  .../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