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

["Gerd Hoffmann" <kraxel@redhat.com>]

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.

> 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