From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: solarflare.com, ip: 148.163.129.52, mailfrom: tpilar@solarflare.com) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by groups.io with SMTP; Tue, 28 May 2019 08:18:56 -0700 X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 0567D10009C for ; Tue, 28 May 2019 15:18:54 +0000 (UTC) Received: from ukex01.SolarFlarecom.com (10.17.10.4) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 28 May 2019 16:18:50 +0100 Received: from ukex01.SolarFlarecom.com ([fe80::3c10:6f38:9305:ac6d]) by ukex01.SolarFlarecom.com ([fe80::3c10:6f38:9305:ac6d%14]) with mapi id 15.00.1395.000; Tue, 28 May 2019 16:18:49 +0100 From: "Tomas Pilar (tpilar)" To: Devel EDK2 Subject: OVMF and SMBIOS Thread-Topic: OVMF and SMBIOS Thread-Index: AdUVZ30zBeYzA30TR5e0gIxQ/SLdyw== Date: Tue, 28 May 2019 15:18:48 +0000 Message-ID: <16be83ee265e46db88af85dc47949e23@ukex01.SolarFlarecom.com> Accept-Language: en-GB, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.17.25.143] x-tm-as-product-ver: SMEX-12.5.0.1300-8.5.1010-24642.003 x-tm-as-result: No-13.791700-8.000000-10 x-tmase-matchedrid: Hbv3glH3SRBHW+94FA8JF8K1Ib9JAALxrogFtKd/P7cLBZEuqIL9SpO9 mQGx4jC3Sa7i4WMGYwF/2SsgU8jyNW7vEKjEI8LygNylVbI/EAyoCf7IdvPAJzrW2rRfTfGrevR Ae5P8R94/+RSNQ9LGXlDQ43dkW3a5LDC3FGTHI3eL6bUMM+bbIsEiXG0R7qDH5DJ1FS+XdBPhiA n4o8o/g1ExP3j0lskRIeGAMtf6YBwuGJVwjRzMf/9N7e3lwkwbYERxjzVaKh3vxOQTFF5KDWii8 WGiB+jQxoLdD62KxEHvGRfD47E7WEBFKHtTm3V6iQy4MG/9StnInWAWA4yE6VwwZNlQvtYaoaiO IyqBG8JqRxjrBolJ6Ahhu1ovy+OgaHj2AWv1orHEWUpSZSQz2OIY/kLX5uaN x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No x-tmase-result: 10--13.791700-8.000000 x-tmase-version: SMEX-12.5.0.1300-8.5.1010-24642.003 MIME-Version: 1.0 X-MDID: 1559056736-Nh0eCUnr-VdS X-Groupsio-MsgNum: 41514 Content-Language: en-US Content-Type: multipart/mixed; boundary="_004_16be83ee265e46db88af85dc47949e23ukex01SolarFlarecomcom_" --_004_16be83ee265e46db88af85dc47949e23ukex01SolarFlarecomcom_ Content-Type: multipart/alternative; boundary="_000_16be83ee265e46db88af85dc47949e23ukex01SolarFlarecomcom_" --_000_16be83ee265e46db88af85dc47949e23ukex01SolarFlarecomcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am trying to create kvm instance using libvirt and Qemu and OVMF that als= o has SMBIOS included. My current version of Qemu only supports type 0 and = type 1 SMBIOS tables so I specify those. However, when I use smbiosview in = the UEFI shell, I get back "SMBIOS not found". I attach my current libvirt xml specification for the kvm host. Does anyone have any immediate ideas? Cheers, Tom --_000_16be83ee265e46db88af85dc47949e23ukex01SolarFlarecomcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I am trying to create kvm instance using libvirt and= Qemu and OVMF that also has SMBIOS included. My current version of Qemu on= ly supports type 0 and type 1 SMBIOS tables so I specify those. However, wh= en I use smbiosview in the UEFI shell, I get back “SMBIOS not found”.

I attach my current libvirt xml specification for th= e kvm host.

Does anyone have any immediate ideas?

Cheers,

Tom

--_000_16be83ee265e46db88af85dc47949e23ukex01SolarFlarecomcom_-- --_004_16be83ee265e46db88af85dc47949e23ukex01SolarFlarecomcom_ Content-Type: text/xml; name="qemu.xml" Content-Description: qemu.xml Content-Disposition: attachment; filename="qemu.xml"; size=2682; creation-date="Tue, 28 May 2019 15:18:22 GMT"; modification-date="Tue, 28 May 2019 15:18:22 GMT" Content-Transfer-Encoding: base64 PGRvbWFpbiB0eXBlPSdrdm0nIGlkPSc1Jz4KICA8bmFtZT5RZW11IFRlc3Q8L25hbWU+CiAgPHV1 aWQ+ZjY0MzMyNjgtOWNjMC00YWVlLTg0OGYtODE5YzI3ZmYzYjYyPC91dWlkPgogIDxtZW1vcnkg dW5pdD0nS2lCJz4yMDk3MTUyPC9tZW1vcnk+CiAgPGN1cnJlbnRNZW1vcnkgdW5pdD0nS2lCJz4y MDk3MTUyPC9jdXJyZW50TWVtb3J5PgogIDx2Y3B1IHBsYWNlbWVudD0nc3RhdGljJz4yPC92Y3B1 PgogIDxyZXNvdXJjZT4KICAgIDxwYXJ0aXRpb24+L21hY2hpbmU8L3BhcnRpdGlvbj4KICA8L3Jl c291cmNlPgogIDxvcz4KICAgIDx0eXBlIGFyY2g9J3g4Nl82NCc+aHZtPC90eXBlPgogICAgPGJv b3RtZW51IGVuYWJsZT0neWVzJyB0aW1lb3V0PSczMDAwJy8+CiAgICA8bG9hZGVyIHJlYWRvbmx5 PSd5ZXMnIHNlY3VyZT0nbm8nIHR5cGU9J3BmbGFzaCc+L3RtcC9vdm1mLXRlc3QvT1ZNRl9DT0RF LmZkPC9sb2FkZXI+CiAgICA8bnZyYW0gdGVtcGxhdGU9Jy90bXAvb3ZtZi10ZXN0L09WTUZfVkFS Uy5mZCc+L3RtcC9vdm1mLXRlc3QvT1ZNRl9WQVJTMi5mZDwvbnZyYW0+CiAgICA8c21iaW9zIG1v ZGU9J3N5c2luZm8nIC8+CiAgPC9vcz4KICA8c3lzaW5mbyB0eXBlPSdzbWJpb3MnPgogICAgPGJp b3M+CiAgICAgIDxlbnRyeSBuYW1lPSd2ZW5kb3InPlNmYyBRZW11PC9lbnRyeT4KICAgIDwvYmlv cz4KICAgIDxzeXN0ZW0+CiAgICAgIDxlbnRyeSBuYW1lPSdtYW51ZmFjdHVyZXInPlFlbXU8L2Vu dHJ5PgogICAgICA8ZW50cnkgbmFtZT0ncHJvZHVjdCc+VmlydC1NYW5hZ2VyPC9lbnRyeT4KICAg ICAgPGVudHJ5IG5hbWU9J3ZlcnNpb24nPjAuOS40PC9lbnRyeT4KICAgICAgPGVudHJ5IG5hbWU9 J3V1aWQnPmY2NDMzMjY4LTljYzAtNGFlZS04NDhmLTgxOWMyN2ZmM2I2MjwvZW50cnk+CiAgICA8 L3N5c3RlbT4KICA8L3N5c2luZm8+CiAgPGZlYXR1cmVzPgogICAgPGFjcGkvPgogICAgPGFwaWMv PgogIDwvZmVhdHVyZXM+CiAgPGNsb2NrIG9mZnNldD0ndXRjJz4KICAgIDx0aW1lciBuYW1lPSdy dGMnIHRpY2twb2xpY3k9J2NhdGNodXAnLz4KICAgIDx0aW1lciBuYW1lPSdwaXQnIHRpY2twb2xp Y3k9J2RlbGF5Jy8+CiAgICA8dGltZXIgbmFtZT0naHBldCcgcHJlc2VudD0nbm8nLz4KICA8L2Ns b2NrPgogIDxvbl9wb3dlcm9mZj5wcmVzZXJ2ZTwvb25fcG93ZXJvZmY+CiAgPG9uX3JlYm9vdD5y ZXN0YXJ0PC9vbl9yZWJvb3Q+CiAgPG9uX2NyYXNoPnByZXNlcnZlPC9vbl9jcmFzaD4KICA8cG0+ CiAgICA8c3VzcGVuZC10by1tZW0gZW5hYmxlZD0nbm8nLz4KICAgIDxzdXNwZW5kLXRvLWRpc2sg ZW5hYmxlZD0nbm8nLz4KICA8L3BtPgogIDxkZXZpY2VzPgogICAgPGVtdWxhdG9yPi91c3IvbGli ZXhlYy9xZW11LWt2bTwvZW11bGF0b3I+CiAgICA8Y29udHJvbGxlciB0eXBlPSdwY2knIGluZGV4 PScwJyBtb2RlbD0ncGNpLXJvb3QnPgogICAgICA8YWxpYXMgbmFtZT0ncGNpLjAnLz4KICAgIDwv Y29udHJvbGxlcj4KICAgIDxob3N0ZGV2IG1vZGU9J3N1YnN5c3RlbScgdHlwZT0ncGNpJyBtYW5h Z2VkPSd5ZXMnPgogICAgICA8c291cmNlPgogICAgICAgIFtBRERSRVNTXQogICAgICA8L3NvdXJj ZT4KICAgIDwvaG9zdGRldj4KICAgIDxzZXJpYWwgdHlwZT0nZmlsZSc+CiAgICAgIDxzb3VyY2Ug cGF0aD0nL3RtcC9vdm1mLXRlc3Qvc2VyaWFsMC5sb2cnLz4KICAgICAgPHRhcmdldCBwb3J0PScw JyAvPgogICAgICA8YWxpYXMgbmFtZT0nc2VyaWFsMCcvPgogICAgPC9zZXJpYWw+CiAgICA8c2Vy aWFsIHR5cGU9J2ZpbGUnPgogICAgICA8c291cmNlIHBhdGg9Jy90bXAvb3ZtZi10ZXN0L3Nlcmlh bDEubG9nJy8+CiAgICAgIDx0YXJnZXQgcG9ydD0nMScgLz4KICAgICAgPGFsaWFzIG5hbWU9J3Nl cmlhbDEnLz4KICAgIDwvc2VyaWFsPgogICAgPGlucHV0IHR5cGU9J21vdXNlJyBidXM9J3BzMic+ CiAgICAgIDxhbGlhcyBuYW1lPSdpbnB1dDEnLz4KICAgIDwvaW5wdXQ+CiAgICA8aW5wdXQgdHlw ZT0na2V5Ym9hcmQnIGJ1cz0ncHMyJz4KICAgICAgPGFsaWFzIG5hbWU9J2lucHV0MicvPgogICAg PC9pbnB1dD4KICAgIDxncmFwaGljcyB0eXBlPSdzcGljZScgcG9ydD0nNTkwMCcgYXV0b3BvcnQ9 J3llcycgbGlzdGVuPScxMjcuMC4wLjEnPgogICAgICA8bGlzdGVuIHR5cGU9J2FkZHJlc3MnIGFk ZHJlc3M9JzEyNy4wLjAuMScvPgogICAgICA8aW1hZ2UgY29tcHJlc3Npb249J29mZicvPgogICAg PC9ncmFwaGljcz4KICAgIDx2aWRlbz4KICAgICAgPG1vZGVsIHR5cGU9J3F4bCcgcmFtPSc2NTUz NicgdnJhbT0nNjU1MzYnIHZnYW1lbT0nMTYzODQnIGhlYWRzPScxJyBwcmltYXJ5PSd5ZXMnLz4K ICAgICAgPGFsaWFzIG5hbWU9J3ZpZGVvMCcvPgogICAgICA8YWRkcmVzcyB0eXBlPSdwY2knIGRv bWFpbj0nMHgwMDAwJyBidXM9JzB4MDAnIHNsb3Q9JzB4MDInIGZ1bmN0aW9uPScweDAnLz4KICAg IDwvdmlkZW8+CiAgICA8cm5nIG1vZGVsPSd2aXJ0aW8nPgogICAgICA8YmFja2VuZCBtb2RlbD0n cmFuZG9tJz4vZGV2L3VyYW5kb208L2JhY2tlbmQ+CiAgICAgIDxhbGlhcyBuYW1lPSdybmcwJy8+ CiAgICAgIDxhZGRyZXNzIHR5cGU9J3BjaScgZG9tYWluPScweDAwMDAnIGJ1cz0nMHgwMCcgc2xv dD0nMHgwOScgZnVuY3Rpb249JzB4MCcvPgogICAgPC9ybmc+CiAgPC9kZXZpY2VzPgo8L2RvbWFp bj4K --_004_16be83ee265e46db88af85dc47949e23ukex01SolarFlarecomcom_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Tue, 28 May 2019 10:06:22 -0700 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 980C4307D935; Tue, 28 May 2019 17:06:07 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-40.rdu2.redhat.com [10.10.120.40]) by smtp.corp.redhat.com (Postfix) with ESMTP id C53825D9DC; Tue, 28 May 2019 17:06:04 +0000 (UTC) Subject: Re: [edk2-devel] OVMF and SMBIOS To: devel@edk2.groups.io, tpilar@solarflare.com References: <16be83ee265e46db88af85dc47949e23@ukex01.SolarFlarecom.com> From: "Laszlo Ersek" Message-ID: Date: Tue, 28 May 2019 19:06:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <16be83ee265e46db88af85dc47949e23@ukex01.SolarFlarecom.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Tue, 28 May 2019 17:06:10 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit On 05/28/19 17:18, Tomas Pilar (tpilar) wrote: > Hi, > > I am trying to create kvm instance using libvirt and Qemu and OVMF that also has SMBIOS included. My current version of Qemu only supports type 0 and type 1 SMBIOS tables so I specify those. However, when I use smbiosview in the UEFI shell, I get back "SMBIOS not found". > > I attach my current libvirt xml specification for the kvm host. > > Does anyone have any immediate ideas? The SMBIOS fw_cfg interface between QEMU and guest firmware was reworked in the QEMU v2.1.0 release (primarily in commit c97294ec1b9e, "SMBIOS: Build aggregate smbios tables and entry point", 2014-05-05). If you use an earlier QEMU release, or else you use a machine type earlier than pc-i440fx-2.1, then the new SMBIOS fw_cfg interface is not exposed to guest firmware. And, upstream OVMF never gained patches for the "legacy" SMBIOS fw_cfg interface. I had posted patches for that in 2013, but they were not accepted. The thread starts here: [edk2] [PATCH 0/3] OvmfPkg: basic SMBIOS support on QEMU https://www.mail-archive.com/edk2-devel@lists.sourceforge.net/msg02917.html We (RH) carried forward these patches for quite some time in RHEL7 and (IIRC) Fedora as well, but QEMU v2.1.0 was released in Aug 2014 if I read the git log right, and so we too dropped the downstream-only patches at some point, in favor of the new interface. Based on your libvirt domain xml... It looks likely that you use the qemu-kvm package that is part of base RHEL7. That package is based on upstream QEMU 1.5.3, and so it indeed lacks support for the "new" SMBIOS interface. If you can use CentOS, you could try the qemu-kvm-ev package instead. (That one is based on upstream 2.12.) Alternatively, you could check the "OVMF-20160202-2.gitd7c0dfa.el7" package (or earlier), which should (a) still include the above-referenced patches, and (b) still run on the 1.5.3-based qemu-kvm emulator. (Later OVMF packages would only provide the SMM_REQUIRE firmware binary, which does not boot on the 1.5.3-based qemu-kvm emulator.) Thanks Laszlo From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: solarflare.com, ip: 148.163.129.52, mailfrom: tpilar@solarflare.com) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by groups.io with SMTP; Wed, 29 May 2019 02:44:16 -0700 X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (webmail.solarflare.com [12.187.104.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id D50C2B40055; Wed, 29 May 2019 09:44:14 +0000 (UTC) Received: from tp-desktop.uk.solarflarecom.com (10.17.20.51) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 29 May 2019 02:44:11 -0700 Subject: Re: [edk2-devel] OVMF and SMBIOS To: , References: <16be83ee265e46db88af85dc47949e23@ukex01.SolarFlarecom.com> From: "Tomas Pilar (tpilar)" Message-ID: <16ce9884-f42e-eefc-062e-a23fdf680b2d@solarflare.com> Date: Wed, 29 May 2019 10:44:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.17.20.51] X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24644.005 X-TM-AS-Result: No-15.514900-4.000000-10 X-TMASE-MatchedRID: gjZGo2H/wj/mLzc6AOD8DfHkpkyUphL9w3BtuOFz4BGmBkXli2IfBKAs suKVAEQ36j33+BFSF5h8XOC51rQ7FYJiSQkXWLNVqjZ865FPtpqsU/iX0A2wj9xSVCzxgUrO2XA Gc2BjwwuggnC4SsEPF8qhBmdRNkjGwqMyRAqToWMlPLVu9PurrVsP0tBwe3qDJt7ZZwvxOlRxWi UYx2RYG9zaad7ROSD8AEjOD2KPH1Mm2WWAELvR+X4neC0h7SAD+KgiyLtJrSD99KEd45s5KpyGB OWQ2FtLQrSBnAN/YDEcKPHe9QJyLEkfXU45UHTJTSMhEUhjtjUr9gVlOIN/6ubnFWpNX1DBBClh B0TZdJiy0eK+KXVK1KldHs0DobMiwdU14NatZIYNwUVhIF6pVgRryDXHx6oXw62uSG5kL1bCCAd NMPTZJ3NLfHcK72CBVZ/agdQpzSEIA+AvHJUe1VSzRMNv1fRD4oSd18bdmwJIXJo+eGm+FOJTPN 6INtjYgt2z3xIftvt+WakqvGWIwo9oUcx9VMLgOX/V8P8ail3BxqsKSczjIvoA9r2LThYYKrauX d3MZDV2EHmbm9v91MurRc498gVnqGEukCcnh/yxI0DkufC2Gjtyyx/FFjQv X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--15.514900-4.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24644.005 X-MDID: 1559123055-DG-QUDJgfsmz Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Content-Language: en-US On 28/05/2019 18:06, Laszlo Ersek wrote: > On 05/28/19 17:18, Tomas Pilar (tpilar) wrote: >> Hi, >> >> I am trying to create kvm instance using libvirt and Qemu and OVMF that also has SMBIOS included. My current version of Qemu only supports type 0 and type 1 SMBIOS tables so I specify those. However, when I use smbiosview in the UEFI shell, I get back "SMBIOS not found". >> >> I attach my current libvirt xml specification for the kvm host. >> >> Does anyone have any immediate ideas? > The SMBIOS fw_cfg interface between QEMU and guest firmware was reworked > in the QEMU v2.1.0 release (primarily in commit c97294ec1b9e, "SMBIOS: > Build aggregate smbios tables and entry point", 2014-05-05). > > If you use an earlier QEMU release, or else you use a machine type > earlier than pc-i440fx-2.1, then the new SMBIOS fw_cfg interface is not > exposed to guest firmware. > > And, upstream OVMF never gained patches for the "legacy" SMBIOS fw_cfg > interface. I had posted patches for that in 2013, but they were not > accepted. The thread starts here: > > [edk2] [PATCH 0/3] OvmfPkg: basic SMBIOS support on QEMU > https://www.mail-archive.com/edk2-devel@lists.sourceforge.net/msg02917.html > > We (RH) carried forward these patches for quite some time in RHEL7 and > (IIRC) Fedora as well, but QEMU v2.1.0 was released in Aug 2014 if I > read the git log right, and so we too dropped the downstream-only > patches at some point, in favor of the new interface. > > Based on your libvirt domain xml... It looks likely that you use the > qemu-kvm package that is part of base RHEL7. That package is based on > upstream QEMU 1.5.3, and so it indeed lacks support for the "new" SMBIOS > interface. If you can use CentOS, you could try the qemu-kvm-ev package > instead. (That one is based on upstream 2.12.) > > Alternatively, you could check the "OVMF-20160202-2.gitd7c0dfa.el7" > package (or earlier), which should (a) still include the > above-referenced patches, and (b) still run on the 1.5.3-based qemu-kvm > emulator. (Later OVMF packages would only provide the SMM_REQUIRE > firmware binary, which does not boot on the 1.5.3-based qemu-kvm emulator.) > > Thanks > Laszlo Thank you Laszlo, that was incredibly thorough! I should be able to work with this. Cheers, Tom