1232876 – OVMF should install a version 2.8 SMBIOS entry point

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1232876 - OVMF should install a version 2.8 SMBIOS entry point

Summary: OVMF should install a version 2.8 SMBIOS entry point

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	ovmf
Sub Component:
Version:	7.1
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Laszlo Ersek
QA Contact:	Virtualization Bugs
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2015-06-17 17:26 UTC by Laszlo Ersek
Modified:	2015-11-19 14:44 UTC (History)
CC List:	12 users (show)
Fixed In Version:	ovmf-20150414-2.gitc9e5618.el7
Doc Type:	Bug Fix
Doc Text:	Previously, OVMF used version 3.0 of the SMBIOS entry point. However, this caused guests with less recent operating systems, such as Red Hat Enterprise Linux 6.6, to be unable to parse the SMBIOS tables. This update sets OVMF to use SMBIOS entry point version 2.8, which ensures that SMBIOS tables can be parsed as expected on older systems.
Clone Of:
Environment:
Last Closed:	2015-11-19 14:44:45 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2015:2465	0	normal	SHIPPED_LIVE	OVMF bug fix and enhancement update	2015-11-19 11:43:18 UTC

Description Laszlo Ersek 2015-06-17 17:26:04 UTC

The "MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf" driver can be controlled with the following three PCDs:

- PcdSmbiosVersion: selects 2.8 vs. 3.0 (and other entry point versions too)
- PcdSmbiosDocRev: if >= 3.0 is selected by the prior PCD, this sets the
  Docrev field. If < 3.0 is selected, then this PCD is not used.
- PcdSmbiosEntryPointProvideMethod: if >= 3.0 has been selected then bit0
  controls if a 32-bit entry point is installed, and bit1 controls if a 64-bit
  entry point is installed (independently of the 32-bit one). If < 3.0 was
  selected, then this PCD is not used.

The latest OVMF in RHEL7 (20150414-1.gitc9e5618.el7) installs a v3.0 entry point, which prevents older guests (eg. RHEL-6.7) from recognizing the SMBIOS tables. OVMF should either statically select 2.8 (via a fixed PcdSmbiosVersion setting), or set it dynamically based on what QEMU generates.

The PCD can be set dynamically only before "MdeModulePkg/Universal/SmbiosDxe" is dispatched, because the entry point of that driver, SmbiosDriverEntryPoint(), reads and stashes the PCD immediately. This implies either PEI logic (PlatformPei perhaps), or some APRIORI DXE hack. Both are quite ugly.

Comment 1 Xiaoqing Wei 2015-06-18 09:14:17 UTC

Hi Laszlo,

How will this work ?

1) is work identical like RHEL 7.1 GA OVMF, that expose 2.8 only ?

 or

2) an option to trigger the selection ?
   eg: -M pc-q35-rhel7.1.0 to keep using 2.8
   and -M pc-q35-rhel7.2.0 to use 3.0.0


if 1), then I think the current SMBIOS test case for OVMF could remain intacted.
if 2), then a revision would be needed.


=====
and BTW, per your mail.
OVMF in RHEL 7.2 would continue to be Tech Preview(due to the SMM stuff no being upstremed yet), right ?


Cheers,
Xiaoqing.

Comment 2 Laszlo Ersek 2015-06-18 13:58:04 UTC

(In reply to Xiaoqing Wei from comment #1)
> Hi Laszlo,
> 
> How will this work ?
> 
> 1) is work identical like RHEL 7.1 GA OVMF, that expose 2.8 only ?
> 
>  or
> 
> 2) an option to trigger the selection ?
>    eg: -M pc-q35-rhel7.1.0 to keep using 2.8
>    and -M pc-q35-rhel7.2.0 to use 3.0.0
> 
> 
> if 1), then I think the current SMBIOS test case for OVMF could remain
> intacted.
> if 2), then a revision would be needed.

The goal is to expose *only* SMBIOS v2.8 in OVMF, regardless of QEMU machine type. The distinction I described earlier is not between v2.8 and v3.0 -- instead the distinction is between two possible implementations to achieve the same goal (which is v2.8).

The first implementation would be statically hardcoding v2.8 in OVMF (downstream only).

The second implementation would be to look at the version field in the SMBIOS entry point that QEMU itself generates, and take the version from there. Since QEMU at the moment only exposes v2.8, regardless of machine type, the end result would be the same. This dynamic approach might be more preferable however, for various reasons, than the static approach. Also this implementation would have to go upstream first.

Some background: qemu-kvm-rhev generates the full SMBIOS payload for the guest firmware to install. This includes the SMBIOS entry point table, and all other SMBIOS tables. The SMBIOS entry point carries the SMBIOS version.

Now, SeaBIOS installs these SMBIOS tables without any processing, so the runtime guest OS will see exactly what QEMU prepared. However, under OVMF things work a bit differently: OVMF can only install the individual tables, but the entry point table (including the version number) comes from the generic edk2 SMBIOS driver. OVMF cannot replace it; the best it can do is to influence the PCD (platform config database) entry that causes the generic driver to install a v2.8 entry point vs. a v3.0 entry point. We can implement this statically in OVMF (easily), or dynamically (more complicated).

In the dynamic case, we could still not install the SMBIOS entry point exactly as it comes from QEMU via fw_cfg -- because the installed entry point table is simpy out of OVMF's hands. What we might be able to do though is to *parse* the version number from the entry point table downloaded from QEMU, set the PCD accordingly, thereby asking the central edk2 SMBIOS driver to install its own entry point table with that version number.

Summary:
- v3.0 is out of question
- v2.8 would not be machine type dependent
- the choice is between various implementations of v2.8,
  not between v2.8 vs. v3.0.

> and BTW, per your mail.
> OVMF in RHEL 7.2 would continue to be Tech Preview(due to the SMM stuff no
> being upstremed yet), right ?

Yes, OVMF remains Tech Preview in 7.2.

Comment 3 Xiaoqing Wei 2015-06-19 02:49:08 UTC

(In reply to Laszlo Ersek from comment #2)

Thanks for the explain, and detail of the backgroud

Comment 4 Laszlo Ersek 2015-06-19 23:41:33 UTC

Posted upstream patch:
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15912

Comment 5 Laszlo Ersek 2015-06-22 17:32:28 UTC

Committed to SVN as r17676; it should soon reach the git mirror too.

Comment 6 Laszlo Ersek 2015-06-22 19:21:26 UTC

Git commit 37baf06b44ba78214aca8806b8516575d3b20db6.

Comment 9 Laszlo Ersek 2015-06-23 11:18:50 UTC

How to test:
- boot a RHEL-6 guest (up to & including 6.7) with qemu-kvm (1.5.3 based)
- boot the same guest with qemu-kvm-rhev, machtype pc-i440fx-rhel7.0.0
- boot the same guest with qemu-kvm-rhev, machtype pc-i440fx-rhel7.2.0

Without the fix, "dmidecode" in the RHEL-6 guest will not find SMBIOS tables. With the fix, "dmidecode" will dump the tables.

(Note that in the third test case, the set of tables dumped by dmidecode will be significantly larger, which is expected.)

Comment 11 Xiaoqing Wei 2015-07-03 06:50:02 UTC

before patching,

qemu-kvm-rhev with mach type 7.2.0,
vm could see smbios 3.0.0, and raise warning of cant parse

qemu-kvm-rhev with mach type 7.0.0, or
qemu-kvm(rhel) with machtype 7.0.0,
vm cant found the entry point of smbios




after patching,

all above 3 vm cfg could see smbios 2.8.0, and parsing correctly,
pls see detail as below:



# rpm -q OVMF qemu-kvm-rhev
OVMF-20150414-1.gitc9e5618.el7.noarch     -> un-patched
qemu-kvm-rhev-2.3.0-7.el7.x86_64

-------------------------------
-machine pc-i440fx-rhel7.2.0,accel=kvm,usb=off
[root@uefi-rhel66 ~]# dmidecode -t 1
# dmidecode 2.12
# SMBIOS entry point at 0x7fed0000
SMBIOS 3.0 present.
# SMBIOS implementations newer than version 2.8 are not
# fully supported by this version of dmidecode.

Handle 0x0100, DMI type 1, 27 bytes
System Information
	Manufacturer: Red Hat
	Product Name: KVM
	Version: pc-i440fx-rhel7.2.0
	Serial Number: Not Specified
	UUID: 6A7063D8-2B59-48D2-B251-EBC06EF184D9
	Wake-up Type: Power Switch
	SKU Number: Not Specified
	Family: Red Hat Enterprise Linux
-------------------------------

===============================

-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off
[root@uefi-rhel66 ~]# dmidecode -t 1
# dmidecode 2.12
/sys/firmware/efi/systab: SMBIOS entry point missing
===============================


[root@dhcp-11-50 ~]# rpm -q OVMF qemu-kvm
OVMF-20150414-1.gitc9e5618.el7.noarch
qemu-kvm-1.5.3-94.el7.x86_64

||||||||||||||||||||||||||||||||||
-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off
[root@uefi-rhel66 ~]# dmidecode -t 1
# dmidecode 2.12
/sys/firmware/efi/systab: SMBIOS entry point missing


||||||||||||||||||||||||||||||||||





[root@dhcp-11-50 ~]# rpm -q OVMF qemu-kvm-rhev
OVMF-20150414-2.gitc9e5618.el7.noarch           -> patched
qemu-kvm-rhev-2.3.0-7.el7.x86_64


-------------------------------
-machine pc-i440fx-rhel7.2.0,accel=kvm,usb=off
[root@uefi-rhel66 ~]# dmidecode -t 1
# dmidecode 2.12
# SMBIOS entry point at 0x7fed0000
SMBIOS 2.8 present.

Handle 0x0100, DMI type 1, 27 bytes
System Information
	Manufacturer: Red Hat
	Product Name: KVM
	Version: pc-i440fx-rhel7.2.0
	Serial Number: Not Specified
	UUID: 6A7063D8-2B59-48D2-B251-EBC06EF184D9
	Wake-up Type: Power Switch
	SKU Number: Not Specified
	Family: Red Hat Enterprise Linux

-------------------------------

===============================
-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off
[root@uefi-rhel66 ~]# dmidecode -t 1
# dmidecode 2.12
# SMBIOS entry point at 0x7fed0000
SMBIOS 2.8 present.

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: Red Hat
	Product Name: KVM
	Version: pc-i440fx-rhel7.0.0
	Serial Number: n/a
	UUID: 6A7063D8-2B59-48D2-B251-EBC06EF184D9
	Wake-up Type: Power Switch
	SKU Number: n/a
	Family: Red Hat Enterprise Linux

===============================

[root@dhcp-11-50 ~]# rpm -q OVMF qemu-kvm
OVMF-20150414-2.gitc9e5618.el7.noarch          -> patched
qemu-kvm-1.5.3-94.el7.x86_64

|||||||||||||||||||||||||||||||||||

-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off
[root@uefi-rhel66 ~]# dmidecode -t 1
# dmidecode 2.12
# SMBIOS entry point at 0x7fed0000
SMBIOS 2.8 present.

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: Red Hat
	Product Name: KVM
	Version: RHEL 7.0.0 PC (i440FX + PIIX, 1996)
	Serial Number: n/a
	UUID: 6A7063D8-2B59-48D2-B251-EBC06EF184D9
	Wake-up Type: Power Switch
	SKU Number: n/a
	Family: Red Hat Enterprise Linux

||||||||||||||||||||||||||||||||||||

Comment 12 Xiaoqing Wei 2015-07-03 06:53:29 UTC

result expected as https://bugzilla.redhat.com/show_bug.cgi?id=1232876#c9
moving to VERIFIED.

Comment 13 errata-xmlrpc 2015-11-19 14:44:45 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2465.html

Note You need to log in before you can comment on or make changes to this bug.