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.web11.19919.1680163451027562171 for ; Thu, 30 Mar 2023 01:04:11 -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 A016B417B2; Thu, 30 Mar 2023 10:04:08 +0200 (CEST) Message-ID: Date: Thu, 30 Mar 2023 10:04:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 From: "Fiona Ebner" Subject: Re: [PATCH v3 1/1] OvmfPkg/SmbiosPlatformDxe: use PcdFirmware* To: Gerd Hoffmann , devel@edk2.groups.io Cc: 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> In-Reply-To: <20221128054020.25531-1-kraxel@redhat.com> Content-Language: de-AT, en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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]. To keep backwards compatibility for [0], it's necessary for us to specify the old vendor value during build. 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: Am 29.03.23 um 18:51 schrieb dann frazier: > 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? Best Regards, Fiona [0]: https://bugzilla.proxmox.com/show_bug.cgi?id=4625 [1]: https://edk2.groups.io/g/devel/message/100922 [2]: dmidecode output differences in a Linux guest when running with a build with OvmfPkg/OvmfPkgIa32X64.dsc: edk2-stable202205: Vendor: EFI Development Kit II / OVMF Version: 0.0.0 Release Date: 02/06/2015 edk2-stable202302: Vendor: EDK II Version: unknown Release Date: unknown