qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
/*
|
|
|
|
* SMBIOS Support
|
|
|
|
*
|
|
|
|
* Copyright (C) 2009 Hewlett-Packard Development Company, L.P.
|
2013-08-16 15:18:29 +02:00
|
|
|
* Copyright (C) 2013 Red Hat, Inc.
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Alex Williamson <alex.williamson@hp.com>
|
2013-08-16 15:18:29 +02:00
|
|
|
* Markus Armbruster <armbru@redhat.com>
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
*
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2. See
|
|
|
|
* the COPYING file in the top-level directory.
|
|
|
|
*
|
2012-01-13 17:44:23 +01:00
|
|
|
* Contributions after 2012-01-13 are licensed under the terms of the
|
|
|
|
* GNU GPL, version 2 or (at your option) any later version.
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
*/
|
|
|
|
|
2016-01-26 19:17:30 +01:00
|
|
|
#include "qemu/osdep.h"
|
2018-06-25 14:42:02 +02:00
|
|
|
#include "qemu/units.h"
|
include/qemu/osdep.h: Don't include qapi/error.h
Commit 57cb38b included qapi/error.h into qemu/osdep.h to get the
Error typedef. Since then, we've moved to include qemu/osdep.h
everywhere. Its file comment explains: "To avoid getting into
possible circular include dependencies, this file should not include
any other QEMU headers, with the exceptions of config-host.h,
compiler.h, os-posix.h and os-win32.h, all of which are doing a
similar job to this file and are under similar constraints."
qapi/error.h doesn't do a similar job, and it doesn't adhere to
similar constraints: it includes qapi-types.h. That's in excess of
100KiB of crap most .c files don't actually need.
Add the typedef to qemu/typedefs.h, and include that instead of
qapi/error.h. Include qapi/error.h in .c files that need it and don't
get it now. Include qapi-types.h in qom/object.h for uint16List.
Update scripts/clean-includes accordingly. Update it further to match
reality: replace config.h by config-target.h, add sysemu/os-posix.h,
sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h
comment quoted above similarly.
This reduces the number of objects depending on qapi/error.h from "all
of them" to less than a third. Unfortunately, the number depending on
qapi-types.h shrinks only a little. More work is needed for that one.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
[Fix compilation without the spice devel packages. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-14 09:01:28 +01:00
|
|
|
#include "qapi/error.h"
|
2013-08-16 15:18:29 +02:00
|
|
|
#include "qemu/config-file.h"
|
2013-06-07 15:00:33 +02:00
|
|
|
#include "qemu/error-report.h"
|
2019-05-23 16:35:07 +02:00
|
|
|
#include "qemu/module.h"
|
2018-02-01 12:18:46 +01:00
|
|
|
#include "qemu/option.h"
|
2012-12-17 18:20:04 +01:00
|
|
|
#include "sysemu/sysemu.h"
|
2016-09-21 06:27:14 +02:00
|
|
|
#include "qemu/uuid.h"
|
2018-12-11 17:34:06 +01:00
|
|
|
#include "hw/firmware/smbios.h"
|
2013-02-04 15:40:22 +01:00
|
|
|
#include "hw/loader.h"
|
2019-05-18 22:54:20 +02:00
|
|
|
#include "hw/boards.h"
|
hw/smbios: support for type 41 (onboard devices extended information)
Type 41 defines the attributes of devices that are onboard. The
original intent was to imply the BIOS had some level of control over
the enablement of the associated devices.
If network devices are present in this table, by default, udev will
name the corresponding interfaces enoX, X being the instance number.
Without such information, udev will fallback to using the PCI ID and
this usually gives ens3 or ens4. This can be a bit annoying as the
name of the network card may depend on the order of options and may
change if a new PCI device is added earlier on the commande line.
Being able to provide SMBIOS type 41 entry ensure the name of the
interface won't change and helps the user guess the right name without
booting a first time.
This can be invoked with:
$QEMU -netdev user,id=internet
-device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet,id=internet-dev \
-smbios type=41,designation='Onboard LAN',instance=1,kind=ethernet,pcidev=internet-dev
The PCI segment is assumed to be 0. This should hold true for most
cases.
$ dmidecode -t 41
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard LAN
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:09.0
$ ip -brief a
lo UNKNOWN 127.0.0.1/8 ::1/128
eno1 UP 10.0.2.14/24 fec0::5254:ff:fe00:42/64 fe80::5254:ff:fe00:42/64
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
Message-Id: <20210401171138.62970-1-vincent@bernat.ch>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-04-01 19:11:38 +02:00
|
|
|
#include "hw/pci/pci_bus.h"
|
2022-12-22 11:03:28 +01:00
|
|
|
#include "hw/pci/pci_device.h"
|
2016-06-10 11:15:40 +02:00
|
|
|
#include "smbios_build.h"
|
2014-04-23 15:42:38 +02:00
|
|
|
|
|
|
|
/* legacy structures and constants for <= 2.0 machines */
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
struct smbios_header {
|
|
|
|
uint16_t length;
|
|
|
|
uint8_t type;
|
2011-08-31 12:38:01 +02:00
|
|
|
} QEMU_PACKED;
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
|
|
|
|
struct smbios_field {
|
|
|
|
struct smbios_header header;
|
|
|
|
uint8_t type;
|
|
|
|
uint16_t offset;
|
|
|
|
uint8_t data[];
|
2011-08-31 12:38:01 +02:00
|
|
|
} QEMU_PACKED;
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
|
|
|
|
struct smbios_table {
|
|
|
|
struct smbios_header header;
|
|
|
|
uint8_t data[];
|
2011-08-31 12:38:01 +02:00
|
|
|
} QEMU_PACKED;
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
|
|
|
|
#define SMBIOS_FIELD_ENTRY 0
|
|
|
|
#define SMBIOS_TABLE_ENTRY 1
|
|
|
|
|
|
|
|
static uint8_t *smbios_entries;
|
|
|
|
static size_t smbios_entries_len;
|
2014-04-23 15:42:42 +02:00
|
|
|
static bool smbios_legacy = true;
|
smbios: Encode UUID according to SMBIOS specification
Differently from older versions, SMBIOS version 2.6 is explicit about
the encoding of UUID fields:
> Although RFC 4122 recommends network byte order for all fields, the PC
> industry (including the ACPI, UEFI, and Microsoft specifications) has
> consistently used little-endian byte encoding for the first three fields:
> time_low, time_mid, time_hi_and_version. The same encoding, also known as
> wire format, should also be used for the SMBIOS representation of the UUID.
>
> The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented
> as 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.
The dmidecode tool implements this and decodes the above "wire format"
when SMBIOS version >= 2.6. We moved from SMBIOS version 2.4 to 2.8 when
we started building the SMBIOS entry point inside QEMU, on commit
c97294ec1b9e36887e119589d456557d72ab37b5.
Change smbios_build_type_1_table() to encode the UUID as specified.
To make sure we won't change the guest-visible UUID when upgrading to a
newer QEMU version, keep the old behavior on pc-*-2.1 and older.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-10-29 14:26:08 +01:00
|
|
|
static bool smbios_uuid_encoded = true;
|
2014-04-23 15:42:38 +02:00
|
|
|
/* end: legacy structures & constants for <= 2.0 machines */
|
|
|
|
|
|
|
|
|
2016-06-10 11:15:40 +02:00
|
|
|
uint8_t *smbios_tables;
|
|
|
|
size_t smbios_tables_len;
|
|
|
|
unsigned smbios_table_max;
|
|
|
|
unsigned smbios_table_cnt;
|
2021-10-26 17:10:58 +02:00
|
|
|
static SmbiosEntryPointType smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_32;
|
2015-09-07 11:39:28 +02:00
|
|
|
|
|
|
|
static SmbiosEntryPoint ep;
|
2014-04-23 15:42:42 +02:00
|
|
|
|
2009-07-31 19:49:14 +02:00
|
|
|
static int smbios_type4_count = 0;
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
static bool smbios_immutable;
|
2014-04-23 15:42:42 +02:00
|
|
|
static bool smbios_have_defaults;
|
|
|
|
static uint32_t smbios_cpuid_version, smbios_cpuid_features, smbios_smp_sockets;
|
2009-07-31 19:49:14 +02:00
|
|
|
|
2014-04-23 15:42:41 +02:00
|
|
|
static DECLARE_BITMAP(have_binfile_bitmap, SMBIOS_MAX_TYPE+1);
|
|
|
|
static DECLARE_BITMAP(have_fields_bitmap, SMBIOS_MAX_TYPE+1);
|
2013-08-16 15:18:30 +02:00
|
|
|
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
static struct {
|
|
|
|
const char *vendor, *version, *date;
|
2014-05-19 16:09:54 +02:00
|
|
|
bool have_major_minor, uefi;
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
uint8_t major, minor;
|
|
|
|
} type0;
|
|
|
|
|
|
|
|
static struct {
|
|
|
|
const char *manufacturer, *product, *version, *serial, *sku, *family;
|
2016-09-21 06:27:22 +02:00
|
|
|
/* uuid is in qemu_uuid */
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
} type1;
|
|
|
|
|
2014-04-23 15:42:42 +02:00
|
|
|
static struct {
|
|
|
|
const char *manufacturer, *product, *version, *serial, *asset, *location;
|
|
|
|
} type2;
|
|
|
|
|
|
|
|
static struct {
|
|
|
|
const char *manufacturer, *version, *serial, *asset, *sku;
|
|
|
|
} type3;
|
|
|
|
|
2020-08-06 05:56:33 +02:00
|
|
|
/*
|
|
|
|
* SVVP requires max_speed and current_speed to be set and not being
|
|
|
|
* 0 which counts as unknown (SMBIOS 3.1.0/Table 21). Set the
|
|
|
|
* default value to 2000MHz as we did before.
|
|
|
|
*/
|
|
|
|
#define DEFAULT_CPU_SPEED 2000
|
|
|
|
|
2014-04-23 15:42:42 +02:00
|
|
|
static struct {
|
2024-01-23 19:42:26 +01:00
|
|
|
uint16_t processor_family;
|
2014-04-23 15:42:42 +02:00
|
|
|
const char *sock_pfx, *manufacturer, *version, *serial, *asset, *part;
|
2020-08-06 05:56:33 +02:00
|
|
|
uint64_t max_speed;
|
|
|
|
uint64_t current_speed;
|
2022-01-25 17:31:18 +01:00
|
|
|
uint64_t processor_id;
|
2020-08-06 05:56:33 +02:00
|
|
|
} type4 = {
|
|
|
|
.max_speed = DEFAULT_CPU_SPEED,
|
2022-01-25 17:31:18 +01:00
|
|
|
.current_speed = DEFAULT_CPU_SPEED,
|
|
|
|
.processor_id = 0,
|
2024-01-23 19:42:26 +01:00
|
|
|
.processor_family = 0x01, /* Other */
|
2020-08-06 05:56:33 +02:00
|
|
|
};
|
2014-04-23 15:42:42 +02:00
|
|
|
|
hw/smbios: support for type 8 (port connector)
PATCH v1: add support for SMBIOS type 8 to qemu
PATCH v2: incorporate patch v1 feedback and add smbios type=8 to qemu-options
internal_reference: internal reference designator
external_reference: external reference designator
connector_type: hex value for port connector type (see SMBIOS 7.9.2)
port_type: hex value for port type (see SMBIOS 7.9.3)
After studying various vendor implementationsi (Dell, Lenovo, MSI),
the value of internal connector type was hard-coded to 0x0 (None).
Example usage:
-smbios type=8,internal_reference=JUSB1,external_reference=USB1,connector_type=0x12,port_type=0x10 \
-smbios type=8,internal_reference=JAUD1,external_reference="Audio Jack",connector_type=0x1f,port_type=0x1d \
-smbios type=8,internal_reference=LAN,external_reference=Ethernet,connector_type=0x0b,port_type=0x1f \
-smbios type=8,internal_reference=PS2,external_reference=Mouse,connector_type=0x0f,port_type=0x0e \
-smbios type=8,internal_reference=PS2,external_reference=Keyboard,connector_type=0x0f,port_type=0x0d
Signed-off-by: Hal Martin <hal.martin@gmail.com>
Message-Id: <20220812135153.17859-1-hal.martin@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-08-12 15:51:53 +02:00
|
|
|
struct type8_instance {
|
|
|
|
const char *internal_reference, *external_reference;
|
|
|
|
uint8_t connector_type, port_type;
|
|
|
|
QTAILQ_ENTRY(type8_instance) next;
|
|
|
|
};
|
|
|
|
static QTAILQ_HEAD(, type8_instance) type8 = QTAILQ_HEAD_INITIALIZER(type8);
|
|
|
|
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
static struct {
|
|
|
|
size_t nvalues;
|
2020-09-23 15:38:02 +02:00
|
|
|
char **values;
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
} type11;
|
|
|
|
|
2014-04-23 15:42:42 +02:00
|
|
|
static struct {
|
|
|
|
const char *loc_pfx, *bank, *manufacturer, *serial, *asset, *part;
|
2015-03-11 18:58:01 +01:00
|
|
|
uint16_t speed;
|
2014-04-23 15:42:42 +02:00
|
|
|
} type17;
|
|
|
|
|
hw/smbios: support for type 41 (onboard devices extended information)
Type 41 defines the attributes of devices that are onboard. The
original intent was to imply the BIOS had some level of control over
the enablement of the associated devices.
If network devices are present in this table, by default, udev will
name the corresponding interfaces enoX, X being the instance number.
Without such information, udev will fallback to using the PCI ID and
this usually gives ens3 or ens4. This can be a bit annoying as the
name of the network card may depend on the order of options and may
change if a new PCI device is added earlier on the commande line.
Being able to provide SMBIOS type 41 entry ensure the name of the
interface won't change and helps the user guess the right name without
booting a first time.
This can be invoked with:
$QEMU -netdev user,id=internet
-device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet,id=internet-dev \
-smbios type=41,designation='Onboard LAN',instance=1,kind=ethernet,pcidev=internet-dev
The PCI segment is assumed to be 0. This should hold true for most
cases.
$ dmidecode -t 41
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard LAN
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:09.0
$ ip -brief a
lo UNKNOWN 127.0.0.1/8 ::1/128
eno1 UP 10.0.2.14/24 fec0::5254:ff:fe00:42/64 fe80::5254:ff:fe00:42/64
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
Message-Id: <20210401171138.62970-1-vincent@bernat.ch>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-04-01 19:11:38 +02:00
|
|
|
static QEnumLookup type41_kind_lookup = {
|
|
|
|
.array = (const char *const[]) {
|
|
|
|
"other",
|
|
|
|
"unknown",
|
|
|
|
"video",
|
|
|
|
"scsi",
|
|
|
|
"ethernet",
|
|
|
|
"tokenring",
|
|
|
|
"sound",
|
|
|
|
"pata",
|
|
|
|
"sata",
|
|
|
|
"sas",
|
|
|
|
},
|
|
|
|
.size = 10
|
|
|
|
};
|
|
|
|
struct type41_instance {
|
|
|
|
const char *designation, *pcidev;
|
|
|
|
uint8_t instance, kind;
|
|
|
|
QTAILQ_ENTRY(type41_instance) next;
|
|
|
|
};
|
|
|
|
static QTAILQ_HEAD(, type41_instance) type41 = QTAILQ_HEAD_INITIALIZER(type41);
|
|
|
|
|
2013-08-16 15:18:29 +02:00
|
|
|
static QemuOptsList qemu_smbios_opts = {
|
|
|
|
.name = "smbios",
|
|
|
|
.head = QTAILQ_HEAD_INITIALIZER(qemu_smbios_opts.head),
|
|
|
|
.desc = {
|
|
|
|
/*
|
|
|
|
* no elements => accept any params
|
|
|
|
* validation will happen later
|
|
|
|
*/
|
|
|
|
{ /* end of list */ }
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
static const QemuOptDesc qemu_smbios_file_opts[] = {
|
|
|
|
{
|
|
|
|
.name = "file",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "binary file containing an SMBIOS element",
|
|
|
|
},
|
|
|
|
{ /* end of list */ }
|
|
|
|
};
|
|
|
|
|
|
|
|
static const QemuOptDesc qemu_smbios_type0_opts[] = {
|
|
|
|
{
|
|
|
|
.name = "type",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "SMBIOS element type",
|
|
|
|
},{
|
|
|
|
.name = "vendor",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "vendor name",
|
|
|
|
},{
|
|
|
|
.name = "version",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "version number",
|
|
|
|
},{
|
|
|
|
.name = "date",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "release date",
|
|
|
|
},{
|
|
|
|
.name = "release",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "revision number",
|
2014-05-19 16:09:54 +02:00
|
|
|
},{
|
|
|
|
.name = "uefi",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
|
|
|
.help = "uefi support",
|
2013-08-16 15:18:29 +02:00
|
|
|
},
|
|
|
|
{ /* end of list */ }
|
|
|
|
};
|
|
|
|
|
|
|
|
static const QemuOptDesc qemu_smbios_type1_opts[] = {
|
|
|
|
{
|
|
|
|
.name = "type",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "SMBIOS element type",
|
|
|
|
},{
|
|
|
|
.name = "manufacturer",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "manufacturer name",
|
|
|
|
},{
|
|
|
|
.name = "product",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "product name",
|
|
|
|
},{
|
|
|
|
.name = "version",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "version number",
|
|
|
|
},{
|
|
|
|
.name = "serial",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "serial number",
|
|
|
|
},{
|
|
|
|
.name = "uuid",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "UUID",
|
|
|
|
},{
|
|
|
|
.name = "sku",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "SKU number",
|
|
|
|
},{
|
|
|
|
.name = "family",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "family name",
|
|
|
|
},
|
|
|
|
{ /* end of list */ }
|
|
|
|
};
|
|
|
|
|
2014-04-23 15:42:42 +02:00
|
|
|
static const QemuOptDesc qemu_smbios_type2_opts[] = {
|
|
|
|
{
|
|
|
|
.name = "type",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "SMBIOS element type",
|
|
|
|
},{
|
|
|
|
.name = "manufacturer",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "manufacturer name",
|
|
|
|
},{
|
|
|
|
.name = "product",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "product name",
|
|
|
|
},{
|
|
|
|
.name = "version",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "version number",
|
|
|
|
},{
|
|
|
|
.name = "serial",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "serial number",
|
|
|
|
},{
|
|
|
|
.name = "asset",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "asset tag number",
|
|
|
|
},{
|
|
|
|
.name = "location",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "location in chassis",
|
|
|
|
},
|
|
|
|
{ /* end of list */ }
|
|
|
|
};
|
|
|
|
|
|
|
|
static const QemuOptDesc qemu_smbios_type3_opts[] = {
|
|
|
|
{
|
|
|
|
.name = "type",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "SMBIOS element type",
|
|
|
|
},{
|
|
|
|
.name = "manufacturer",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "manufacturer name",
|
|
|
|
},{
|
|
|
|
.name = "version",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "version number",
|
|
|
|
},{
|
|
|
|
.name = "serial",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "serial number",
|
|
|
|
},{
|
|
|
|
.name = "asset",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "asset tag number",
|
|
|
|
},{
|
|
|
|
.name = "sku",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "SKU number",
|
|
|
|
},
|
|
|
|
{ /* end of list */ }
|
|
|
|
};
|
|
|
|
|
|
|
|
static const QemuOptDesc qemu_smbios_type4_opts[] = {
|
|
|
|
{
|
|
|
|
.name = "type",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "SMBIOS element type",
|
|
|
|
},{
|
|
|
|
.name = "sock_pfx",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "socket designation string prefix",
|
|
|
|
},{
|
|
|
|
.name = "manufacturer",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "manufacturer name",
|
|
|
|
},{
|
|
|
|
.name = "version",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "version number",
|
2020-08-06 05:56:33 +02:00
|
|
|
},{
|
|
|
|
.name = "max-speed",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "max speed in MHz",
|
|
|
|
},{
|
|
|
|
.name = "current-speed",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "speed at system boot in MHz",
|
2014-04-23 15:42:42 +02:00
|
|
|
},{
|
|
|
|
.name = "serial",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "serial number",
|
|
|
|
},{
|
|
|
|
.name = "asset",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "asset tag number",
|
|
|
|
},{
|
|
|
|
.name = "part",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "part number",
|
2024-01-23 19:42:26 +01:00
|
|
|
}, {
|
|
|
|
.name = "processor-family",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "processor family",
|
2022-01-25 17:31:18 +01:00
|
|
|
}, {
|
|
|
|
.name = "processor-id",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "processor id",
|
2014-04-23 15:42:42 +02:00
|
|
|
},
|
|
|
|
{ /* end of list */ }
|
|
|
|
};
|
|
|
|
|
hw/smbios: support for type 8 (port connector)
PATCH v1: add support for SMBIOS type 8 to qemu
PATCH v2: incorporate patch v1 feedback and add smbios type=8 to qemu-options
internal_reference: internal reference designator
external_reference: external reference designator
connector_type: hex value for port connector type (see SMBIOS 7.9.2)
port_type: hex value for port type (see SMBIOS 7.9.3)
After studying various vendor implementationsi (Dell, Lenovo, MSI),
the value of internal connector type was hard-coded to 0x0 (None).
Example usage:
-smbios type=8,internal_reference=JUSB1,external_reference=USB1,connector_type=0x12,port_type=0x10 \
-smbios type=8,internal_reference=JAUD1,external_reference="Audio Jack",connector_type=0x1f,port_type=0x1d \
-smbios type=8,internal_reference=LAN,external_reference=Ethernet,connector_type=0x0b,port_type=0x1f \
-smbios type=8,internal_reference=PS2,external_reference=Mouse,connector_type=0x0f,port_type=0x0e \
-smbios type=8,internal_reference=PS2,external_reference=Keyboard,connector_type=0x0f,port_type=0x0d
Signed-off-by: Hal Martin <hal.martin@gmail.com>
Message-Id: <20220812135153.17859-1-hal.martin@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-08-12 15:51:53 +02:00
|
|
|
static const QemuOptDesc qemu_smbios_type8_opts[] = {
|
2024-01-29 09:03:08 +01:00
|
|
|
{
|
|
|
|
.name = "type",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "SMBIOS element type",
|
|
|
|
},
|
hw/smbios: support for type 8 (port connector)
PATCH v1: add support for SMBIOS type 8 to qemu
PATCH v2: incorporate patch v1 feedback and add smbios type=8 to qemu-options
internal_reference: internal reference designator
external_reference: external reference designator
connector_type: hex value for port connector type (see SMBIOS 7.9.2)
port_type: hex value for port type (see SMBIOS 7.9.3)
After studying various vendor implementationsi (Dell, Lenovo, MSI),
the value of internal connector type was hard-coded to 0x0 (None).
Example usage:
-smbios type=8,internal_reference=JUSB1,external_reference=USB1,connector_type=0x12,port_type=0x10 \
-smbios type=8,internal_reference=JAUD1,external_reference="Audio Jack",connector_type=0x1f,port_type=0x1d \
-smbios type=8,internal_reference=LAN,external_reference=Ethernet,connector_type=0x0b,port_type=0x1f \
-smbios type=8,internal_reference=PS2,external_reference=Mouse,connector_type=0x0f,port_type=0x0e \
-smbios type=8,internal_reference=PS2,external_reference=Keyboard,connector_type=0x0f,port_type=0x0d
Signed-off-by: Hal Martin <hal.martin@gmail.com>
Message-Id: <20220812135153.17859-1-hal.martin@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-08-12 15:51:53 +02:00
|
|
|
{
|
|
|
|
.name = "internal_reference",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "internal reference designator",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "external_reference",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "external reference designator",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "connector_type",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "connector type",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "port_type",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "port type",
|
|
|
|
},
|
2024-01-29 09:03:08 +01:00
|
|
|
{ /* end of list */ }
|
hw/smbios: support for type 8 (port connector)
PATCH v1: add support for SMBIOS type 8 to qemu
PATCH v2: incorporate patch v1 feedback and add smbios type=8 to qemu-options
internal_reference: internal reference designator
external_reference: external reference designator
connector_type: hex value for port connector type (see SMBIOS 7.9.2)
port_type: hex value for port type (see SMBIOS 7.9.3)
After studying various vendor implementationsi (Dell, Lenovo, MSI),
the value of internal connector type was hard-coded to 0x0 (None).
Example usage:
-smbios type=8,internal_reference=JUSB1,external_reference=USB1,connector_type=0x12,port_type=0x10 \
-smbios type=8,internal_reference=JAUD1,external_reference="Audio Jack",connector_type=0x1f,port_type=0x1d \
-smbios type=8,internal_reference=LAN,external_reference=Ethernet,connector_type=0x0b,port_type=0x1f \
-smbios type=8,internal_reference=PS2,external_reference=Mouse,connector_type=0x0f,port_type=0x0e \
-smbios type=8,internal_reference=PS2,external_reference=Keyboard,connector_type=0x0f,port_type=0x0d
Signed-off-by: Hal Martin <hal.martin@gmail.com>
Message-Id: <20220812135153.17859-1-hal.martin@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-08-12 15:51:53 +02:00
|
|
|
};
|
|
|
|
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
static const QemuOptDesc qemu_smbios_type11_opts[] = {
|
2024-01-29 09:03:07 +01:00
|
|
|
{
|
|
|
|
.name = "type",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "SMBIOS element type",
|
|
|
|
},
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
{
|
|
|
|
.name = "value",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "OEM string data",
|
|
|
|
},
|
2020-09-23 15:38:02 +02:00
|
|
|
{
|
|
|
|
.name = "path",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "OEM string data from file",
|
|
|
|
},
|
2024-01-29 09:03:07 +01:00
|
|
|
{ /* end of list */ }
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
};
|
|
|
|
|
2014-04-23 15:42:42 +02:00
|
|
|
static const QemuOptDesc qemu_smbios_type17_opts[] = {
|
|
|
|
{
|
|
|
|
.name = "type",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "SMBIOS element type",
|
|
|
|
},{
|
|
|
|
.name = "loc_pfx",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "device locator string prefix",
|
|
|
|
},{
|
|
|
|
.name = "bank",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "bank locator string",
|
|
|
|
},{
|
|
|
|
.name = "manufacturer",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "manufacturer name",
|
|
|
|
},{
|
|
|
|
.name = "serial",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "serial number",
|
|
|
|
},{
|
|
|
|
.name = "asset",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "asset tag number",
|
|
|
|
},{
|
|
|
|
.name = "part",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "part number",
|
2015-03-11 18:58:01 +01:00
|
|
|
},{
|
|
|
|
.name = "speed",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "maximum capable speed",
|
2014-04-23 15:42:42 +02:00
|
|
|
},
|
|
|
|
{ /* end of list */ }
|
|
|
|
};
|
|
|
|
|
hw/smbios: support for type 41 (onboard devices extended information)
Type 41 defines the attributes of devices that are onboard. The
original intent was to imply the BIOS had some level of control over
the enablement of the associated devices.
If network devices are present in this table, by default, udev will
name the corresponding interfaces enoX, X being the instance number.
Without such information, udev will fallback to using the PCI ID and
this usually gives ens3 or ens4. This can be a bit annoying as the
name of the network card may depend on the order of options and may
change if a new PCI device is added earlier on the commande line.
Being able to provide SMBIOS type 41 entry ensure the name of the
interface won't change and helps the user guess the right name without
booting a first time.
This can be invoked with:
$QEMU -netdev user,id=internet
-device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet,id=internet-dev \
-smbios type=41,designation='Onboard LAN',instance=1,kind=ethernet,pcidev=internet-dev
The PCI segment is assumed to be 0. This should hold true for most
cases.
$ dmidecode -t 41
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard LAN
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:09.0
$ ip -brief a
lo UNKNOWN 127.0.0.1/8 ::1/128
eno1 UP 10.0.2.14/24 fec0::5254:ff:fe00:42/64 fe80::5254:ff:fe00:42/64
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
Message-Id: <20210401171138.62970-1-vincent@bernat.ch>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-04-01 19:11:38 +02:00
|
|
|
static const QemuOptDesc qemu_smbios_type41_opts[] = {
|
|
|
|
{
|
|
|
|
.name = "type",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "SMBIOS element type",
|
|
|
|
},{
|
|
|
|
.name = "designation",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "reference designation string",
|
|
|
|
},{
|
|
|
|
.name = "kind",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "device type",
|
|
|
|
.def_value_str = "other",
|
|
|
|
},{
|
|
|
|
.name = "instance",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "device type instance",
|
|
|
|
},{
|
|
|
|
.name = "pcidev",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "PCI device",
|
|
|
|
},
|
|
|
|
{ /* end of list */ }
|
|
|
|
};
|
|
|
|
|
2013-08-16 15:18:29 +02:00
|
|
|
static void smbios_register_config(void)
|
|
|
|
{
|
|
|
|
qemu_add_opts(&qemu_smbios_opts);
|
|
|
|
}
|
|
|
|
|
2016-02-16 21:59:07 +01:00
|
|
|
opts_init(smbios_register_config);
|
2013-08-16 15:18:29 +02:00
|
|
|
|
2020-09-23 15:38:03 +02:00
|
|
|
/*
|
|
|
|
* The SMBIOS 2.1 "structure table length" field in the
|
|
|
|
* entry point uses a 16-bit integer, so we're limited
|
|
|
|
* in total table size
|
|
|
|
*/
|
|
|
|
#define SMBIOS_21_MAX_TABLES_LEN 0xffff
|
|
|
|
|
2019-05-18 22:54:20 +02:00
|
|
|
static void smbios_validate_table(MachineState *ms)
|
2009-07-31 19:49:14 +02:00
|
|
|
{
|
2019-05-18 22:54:20 +02:00
|
|
|
uint32_t expect_t4_count = smbios_legacy ?
|
|
|
|
ms->smp.cpus : smbios_smp_sockets;
|
2014-04-23 15:42:42 +02:00
|
|
|
|
|
|
|
if (smbios_type4_count && smbios_type4_count != expect_t4_count) {
|
|
|
|
error_report("Expected %d SMBIOS Type 4 tables, got %d instead",
|
|
|
|
expect_t4_count, smbios_type4_count);
|
2009-07-31 19:49:14 +02:00
|
|
|
exit(1);
|
|
|
|
}
|
2020-09-23 15:38:03 +02:00
|
|
|
|
2021-10-26 17:10:58 +02:00
|
|
|
if (smbios_ep_type == SMBIOS_ENTRY_POINT_TYPE_32 &&
|
2020-09-23 15:38:03 +02:00
|
|
|
smbios_tables_len > SMBIOS_21_MAX_TABLES_LEN) {
|
|
|
|
error_report("SMBIOS 2.1 table length %zu exceeds %d",
|
|
|
|
smbios_tables_len, SMBIOS_21_MAX_TABLES_LEN);
|
|
|
|
exit(1);
|
|
|
|
}
|
2009-07-31 19:49:14 +02:00
|
|
|
}
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
|
2014-04-23 15:42:38 +02:00
|
|
|
|
|
|
|
/* legacy setup functions for <= 2.0 machines */
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
static void smbios_add_field(int type, int offset, const void *data, size_t len)
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
{
|
|
|
|
struct smbios_field *field;
|
|
|
|
|
|
|
|
if (!smbios_entries) {
|
|
|
|
smbios_entries_len = sizeof(uint16_t);
|
2011-08-21 05:09:37 +02:00
|
|
|
smbios_entries = g_malloc0(smbios_entries_len);
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
}
|
2011-08-21 05:09:37 +02:00
|
|
|
smbios_entries = g_realloc(smbios_entries, smbios_entries_len +
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
sizeof(*field) + len);
|
|
|
|
field = (struct smbios_field *)(smbios_entries + smbios_entries_len);
|
|
|
|
field->header.type = SMBIOS_FIELD_ENTRY;
|
|
|
|
field->header.length = cpu_to_le16(sizeof(*field) + len);
|
|
|
|
|
|
|
|
field->type = type;
|
|
|
|
field->offset = cpu_to_le16(offset);
|
|
|
|
memcpy(field->data, data, len);
|
|
|
|
|
|
|
|
smbios_entries_len += sizeof(*field) + len;
|
|
|
|
(*(uint16_t *)smbios_entries) =
|
|
|
|
cpu_to_le16(le16_to_cpu(*(uint16_t *)smbios_entries) + 1);
|
|
|
|
}
|
|
|
|
|
2013-08-16 15:18:32 +02:00
|
|
|
static void smbios_maybe_add_str(int type, int offset, const char *data)
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
{
|
2013-08-16 15:18:32 +02:00
|
|
|
if (data) {
|
|
|
|
smbios_add_field(type, offset, data, strlen(data) + 1);
|
2013-08-16 15:18:29 +02:00
|
|
|
}
|
2013-08-16 15:18:32 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void smbios_build_type_0_fields(void)
|
|
|
|
{
|
|
|
|
smbios_maybe_add_str(0, offsetof(struct smbios_type_0, vendor_str),
|
|
|
|
type0.vendor);
|
|
|
|
smbios_maybe_add_str(0, offsetof(struct smbios_type_0, bios_version_str),
|
|
|
|
type0.version);
|
|
|
|
smbios_maybe_add_str(0, offsetof(struct smbios_type_0,
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
bios_release_date_str),
|
2013-08-16 15:18:32 +02:00
|
|
|
type0.date);
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
if (type0.have_major_minor) {
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
smbios_add_field(0, offsetof(struct smbios_type_0,
|
2013-06-07 15:00:34 +02:00
|
|
|
system_bios_major_release),
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
&type0.major, 1);
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
smbios_add_field(0, offsetof(struct smbios_type_0,
|
2013-06-07 15:00:34 +02:00
|
|
|
system_bios_minor_release),
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
&type0.minor, 1);
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
static void smbios_build_type_1_fields(void)
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
{
|
2013-08-16 15:18:32 +02:00
|
|
|
smbios_maybe_add_str(1, offsetof(struct smbios_type_1, manufacturer_str),
|
|
|
|
type1.manufacturer);
|
|
|
|
smbios_maybe_add_str(1, offsetof(struct smbios_type_1, product_name_str),
|
|
|
|
type1.product);
|
|
|
|
smbios_maybe_add_str(1, offsetof(struct smbios_type_1, version_str),
|
|
|
|
type1.version);
|
|
|
|
smbios_maybe_add_str(1, offsetof(struct smbios_type_1, serial_number_str),
|
|
|
|
type1.serial);
|
|
|
|
smbios_maybe_add_str(1, offsetof(struct smbios_type_1, sku_number_str),
|
|
|
|
type1.sku);
|
|
|
|
smbios_maybe_add_str(1, offsetof(struct smbios_type_1, family_str),
|
|
|
|
type1.family);
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
if (qemu_uuid_set) {
|
smbios: Encode UUID according to SMBIOS specification
Differently from older versions, SMBIOS version 2.6 is explicit about
the encoding of UUID fields:
> Although RFC 4122 recommends network byte order for all fields, the PC
> industry (including the ACPI, UEFI, and Microsoft specifications) has
> consistently used little-endian byte encoding for the first three fields:
> time_low, time_mid, time_hi_and_version. The same encoding, also known as
> wire format, should also be used for the SMBIOS representation of the UUID.
>
> The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented
> as 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.
The dmidecode tool implements this and decodes the above "wire format"
when SMBIOS version >= 2.6. We moved from SMBIOS version 2.4 to 2.8 when
we started building the SMBIOS entry point inside QEMU, on commit
c97294ec1b9e36887e119589d456557d72ab37b5.
Change smbios_build_type_1_table() to encode the UUID as specified.
To make sure we won't change the guest-visible UUID when upgrading to a
newer QEMU version, keep the old behavior on pc-*-2.1 and older.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-10-29 14:26:08 +01:00
|
|
|
/* We don't encode the UUID in the "wire format" here because this
|
|
|
|
* function is for legacy mode and needs to keep the guest ABI, and
|
|
|
|
* because we don't know what's the SMBIOS version advertised by the
|
|
|
|
* BIOS.
|
|
|
|
*/
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
smbios_add_field(1, offsetof(struct smbios_type_1, uuid),
|
2016-09-21 06:27:22 +02:00
|
|
|
&qemu_uuid, 16);
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-05-18 22:54:20 +02:00
|
|
|
uint8_t *smbios_get_table_legacy(MachineState *ms, size_t *length)
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
{
|
2014-04-23 15:42:42 +02:00
|
|
|
if (!smbios_legacy) {
|
|
|
|
*length = 0;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
if (!smbios_immutable) {
|
|
|
|
smbios_build_type_0_fields();
|
|
|
|
smbios_build_type_1_fields();
|
2019-05-18 22:54:20 +02:00
|
|
|
smbios_validate_table(ms);
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
smbios_immutable = true;
|
|
|
|
}
|
|
|
|
*length = smbios_entries_len;
|
|
|
|
return smbios_entries;
|
|
|
|
}
|
2014-04-23 15:42:38 +02:00
|
|
|
/* end: legacy setup functions for <= 2.0 machines */
|
|
|
|
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
|
2016-06-10 11:15:40 +02:00
|
|
|
bool smbios_skip_table(uint8_t type, bool required_table)
|
2014-04-23 15:42:42 +02:00
|
|
|
{
|
|
|
|
if (test_bit(type, have_binfile_bitmap)) {
|
|
|
|
return true; /* user provided their own binary blob(s) */
|
|
|
|
}
|
|
|
|
if (test_bit(type, have_fields_bitmap)) {
|
|
|
|
return false; /* user provided fields via command line */
|
|
|
|
}
|
|
|
|
if (smbios_have_defaults && required_table) {
|
|
|
|
return false; /* we're building tables, and this one's required */
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2022-02-23 15:33:20 +01:00
|
|
|
#define T0_BASE 0x000
|
|
|
|
#define T1_BASE 0x100
|
|
|
|
#define T2_BASE 0x200
|
|
|
|
#define T3_BASE 0x300
|
|
|
|
#define T4_BASE 0x400
|
|
|
|
#define T11_BASE 0xe00
|
|
|
|
|
|
|
|
#define T16_BASE 0x1000
|
|
|
|
#define T17_BASE 0x1100
|
|
|
|
#define T19_BASE 0x1300
|
|
|
|
#define T32_BASE 0x2000
|
|
|
|
#define T41_BASE 0x2900
|
|
|
|
#define T127_BASE 0x7F00
|
|
|
|
|
2014-04-23 15:42:42 +02:00
|
|
|
static void smbios_build_type_0_table(void)
|
|
|
|
{
|
2022-02-23 15:33:20 +01:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(0, T0_BASE, false); /* optional, leave up to BIOS */
|
2014-04-23 15:42:42 +02:00
|
|
|
|
|
|
|
SMBIOS_TABLE_SET_STR(0, vendor_str, type0.vendor);
|
|
|
|
SMBIOS_TABLE_SET_STR(0, bios_version_str, type0.version);
|
|
|
|
|
2014-05-19 16:09:53 +02:00
|
|
|
t->bios_starting_address_segment = cpu_to_le16(0xE800); /* from SeaBIOS */
|
2014-04-23 15:42:42 +02:00
|
|
|
|
|
|
|
SMBIOS_TABLE_SET_STR(0, bios_release_date_str, type0.date);
|
|
|
|
|
|
|
|
t->bios_rom_size = 0; /* hardcoded in SeaBIOS with FIXME comment */
|
|
|
|
|
2014-05-19 16:09:54 +02:00
|
|
|
t->bios_characteristics = cpu_to_le64(0x08); /* Not supported */
|
2014-04-23 15:42:42 +02:00
|
|
|
t->bios_characteristics_extension_bytes[0] = 0;
|
2014-05-19 16:09:54 +02:00
|
|
|
t->bios_characteristics_extension_bytes[1] = 0x14; /* TCD/SVVP | VM */
|
|
|
|
if (type0.uefi) {
|
|
|
|
t->bios_characteristics_extension_bytes[1] |= 0x08; /* |= UEFI */
|
|
|
|
}
|
2014-04-23 15:42:42 +02:00
|
|
|
|
|
|
|
if (type0.have_major_minor) {
|
|
|
|
t->system_bios_major_release = type0.major;
|
|
|
|
t->system_bios_minor_release = type0.minor;
|
|
|
|
} else {
|
|
|
|
t->system_bios_major_release = 0;
|
|
|
|
t->system_bios_minor_release = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* hardcoded in SeaBIOS */
|
|
|
|
t->embedded_controller_major_release = 0xFF;
|
|
|
|
t->embedded_controller_minor_release = 0xFF;
|
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
}
|
|
|
|
|
smbios: Encode UUID according to SMBIOS specification
Differently from older versions, SMBIOS version 2.6 is explicit about
the encoding of UUID fields:
> Although RFC 4122 recommends network byte order for all fields, the PC
> industry (including the ACPI, UEFI, and Microsoft specifications) has
> consistently used little-endian byte encoding for the first three fields:
> time_low, time_mid, time_hi_and_version. The same encoding, also known as
> wire format, should also be used for the SMBIOS representation of the UUID.
>
> The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented
> as 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.
The dmidecode tool implements this and decodes the above "wire format"
when SMBIOS version >= 2.6. We moved from SMBIOS version 2.4 to 2.8 when
we started building the SMBIOS entry point inside QEMU, on commit
c97294ec1b9e36887e119589d456557d72ab37b5.
Change smbios_build_type_1_table() to encode the UUID as specified.
To make sure we won't change the guest-visible UUID when upgrading to a
newer QEMU version, keep the old behavior on pc-*-2.1 and older.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-10-29 14:26:08 +01:00
|
|
|
/* Encode UUID from the big endian encoding described on RFC4122 to the wire
|
|
|
|
* format specified by SMBIOS version 2.6.
|
|
|
|
*/
|
2016-09-21 06:27:22 +02:00
|
|
|
static void smbios_encode_uuid(struct smbios_uuid *uuid, QemuUUID *in)
|
smbios: Encode UUID according to SMBIOS specification
Differently from older versions, SMBIOS version 2.6 is explicit about
the encoding of UUID fields:
> Although RFC 4122 recommends network byte order for all fields, the PC
> industry (including the ACPI, UEFI, and Microsoft specifications) has
> consistently used little-endian byte encoding for the first three fields:
> time_low, time_mid, time_hi_and_version. The same encoding, also known as
> wire format, should also be used for the SMBIOS representation of the UUID.
>
> The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented
> as 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.
The dmidecode tool implements this and decodes the above "wire format"
when SMBIOS version >= 2.6. We moved from SMBIOS version 2.4 to 2.8 when
we started building the SMBIOS entry point inside QEMU, on commit
c97294ec1b9e36887e119589d456557d72ab37b5.
Change smbios_build_type_1_table() to encode the UUID as specified.
To make sure we won't change the guest-visible UUID when upgrading to a
newer QEMU version, keep the old behavior on pc-*-2.1 and older.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-10-29 14:26:08 +01:00
|
|
|
{
|
2016-09-28 16:38:10 +02:00
|
|
|
memcpy(uuid, in, 16);
|
smbios: Encode UUID according to SMBIOS specification
Differently from older versions, SMBIOS version 2.6 is explicit about
the encoding of UUID fields:
> Although RFC 4122 recommends network byte order for all fields, the PC
> industry (including the ACPI, UEFI, and Microsoft specifications) has
> consistently used little-endian byte encoding for the first three fields:
> time_low, time_mid, time_hi_and_version. The same encoding, also known as
> wire format, should also be used for the SMBIOS representation of the UUID.
>
> The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented
> as 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.
The dmidecode tool implements this and decodes the above "wire format"
when SMBIOS version >= 2.6. We moved from SMBIOS version 2.4 to 2.8 when
we started building the SMBIOS entry point inside QEMU, on commit
c97294ec1b9e36887e119589d456557d72ab37b5.
Change smbios_build_type_1_table() to encode the UUID as specified.
To make sure we won't change the guest-visible UUID when upgrading to a
newer QEMU version, keep the old behavior on pc-*-2.1 and older.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-10-29 14:26:08 +01:00
|
|
|
if (smbios_uuid_encoded) {
|
|
|
|
uuid->time_low = bswap32(uuid->time_low);
|
|
|
|
uuid->time_mid = bswap16(uuid->time_mid);
|
|
|
|
uuid->time_hi_and_version = bswap16(uuid->time_hi_and_version);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-04-23 15:42:42 +02:00
|
|
|
static void smbios_build_type_1_table(void)
|
|
|
|
{
|
2022-02-23 15:33:20 +01:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(1, T1_BASE, true); /* required */
|
2014-04-23 15:42:42 +02:00
|
|
|
|
|
|
|
SMBIOS_TABLE_SET_STR(1, manufacturer_str, type1.manufacturer);
|
|
|
|
SMBIOS_TABLE_SET_STR(1, product_name_str, type1.product);
|
|
|
|
SMBIOS_TABLE_SET_STR(1, version_str, type1.version);
|
|
|
|
SMBIOS_TABLE_SET_STR(1, serial_number_str, type1.serial);
|
|
|
|
if (qemu_uuid_set) {
|
2016-09-21 06:27:22 +02:00
|
|
|
smbios_encode_uuid(&t->uuid, &qemu_uuid);
|
2014-04-23 15:42:42 +02:00
|
|
|
} else {
|
smbios: Encode UUID according to SMBIOS specification
Differently from older versions, SMBIOS version 2.6 is explicit about
the encoding of UUID fields:
> Although RFC 4122 recommends network byte order for all fields, the PC
> industry (including the ACPI, UEFI, and Microsoft specifications) has
> consistently used little-endian byte encoding for the first three fields:
> time_low, time_mid, time_hi_and_version. The same encoding, also known as
> wire format, should also be used for the SMBIOS representation of the UUID.
>
> The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented
> as 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.
The dmidecode tool implements this and decodes the above "wire format"
when SMBIOS version >= 2.6. We moved from SMBIOS version 2.4 to 2.8 when
we started building the SMBIOS entry point inside QEMU, on commit
c97294ec1b9e36887e119589d456557d72ab37b5.
Change smbios_build_type_1_table() to encode the UUID as specified.
To make sure we won't change the guest-visible UUID when upgrading to a
newer QEMU version, keep the old behavior on pc-*-2.1 and older.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-10-29 14:26:08 +01:00
|
|
|
memset(&t->uuid, 0, 16);
|
2014-04-23 15:42:42 +02:00
|
|
|
}
|
|
|
|
t->wake_up_type = 0x06; /* power switch */
|
|
|
|
SMBIOS_TABLE_SET_STR(1, sku_number_str, type1.sku);
|
|
|
|
SMBIOS_TABLE_SET_STR(1, family_str, type1.family);
|
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void smbios_build_type_2_table(void)
|
|
|
|
{
|
2022-02-23 15:33:20 +01:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(2, T2_BASE, false); /* optional */
|
2014-04-23 15:42:42 +02:00
|
|
|
|
|
|
|
SMBIOS_TABLE_SET_STR(2, manufacturer_str, type2.manufacturer);
|
|
|
|
SMBIOS_TABLE_SET_STR(2, product_str, type2.product);
|
|
|
|
SMBIOS_TABLE_SET_STR(2, version_str, type2.version);
|
|
|
|
SMBIOS_TABLE_SET_STR(2, serial_number_str, type2.serial);
|
|
|
|
SMBIOS_TABLE_SET_STR(2, asset_tag_number_str, type2.asset);
|
|
|
|
t->feature_flags = 0x01; /* Motherboard */
|
|
|
|
SMBIOS_TABLE_SET_STR(2, location_str, type2.location);
|
2014-05-19 16:09:53 +02:00
|
|
|
t->chassis_handle = cpu_to_le16(0x300); /* Type 3 (System enclosure) */
|
2014-04-23 15:42:42 +02:00
|
|
|
t->board_type = 0x0A; /* Motherboard */
|
|
|
|
t->contained_element_count = 0;
|
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void smbios_build_type_3_table(void)
|
|
|
|
{
|
2022-02-23 15:33:20 +01:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(3, T3_BASE, true); /* required */
|
2014-04-23 15:42:42 +02:00
|
|
|
|
|
|
|
SMBIOS_TABLE_SET_STR(3, manufacturer_str, type3.manufacturer);
|
|
|
|
t->type = 0x01; /* Other */
|
|
|
|
SMBIOS_TABLE_SET_STR(3, version_str, type3.version);
|
|
|
|
SMBIOS_TABLE_SET_STR(3, serial_number_str, type3.serial);
|
|
|
|
SMBIOS_TABLE_SET_STR(3, asset_tag_number_str, type3.asset);
|
|
|
|
t->boot_up_state = 0x03; /* Safe */
|
|
|
|
t->power_supply_state = 0x03; /* Safe */
|
|
|
|
t->thermal_state = 0x03; /* Safe */
|
|
|
|
t->security_status = 0x02; /* Unknown */
|
2014-05-19 16:09:53 +02:00
|
|
|
t->oem_defined = cpu_to_le32(0);
|
2014-04-23 15:42:42 +02:00
|
|
|
t->height = 0;
|
|
|
|
t->number_of_power_cords = 0;
|
|
|
|
t->contained_element_count = 0;
|
2019-02-15 16:36:00 +01:00
|
|
|
t->contained_element_record_length = 0;
|
2014-04-23 15:42:42 +02:00
|
|
|
SMBIOS_TABLE_SET_STR(3, sku_number_str, type3.sku);
|
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
}
|
|
|
|
|
2019-05-18 22:54:20 +02:00
|
|
|
static void smbios_build_type_4_table(MachineState *ms, unsigned instance)
|
2014-04-23 15:42:42 +02:00
|
|
|
{
|
|
|
|
char sock_str[128];
|
2022-10-11 13:17:27 +02:00
|
|
|
size_t tbl_len = SMBIOS_TYPE_4_LEN_V28;
|
2023-06-28 15:54:36 +02:00
|
|
|
unsigned threads_per_socket;
|
2023-06-28 15:54:37 +02:00
|
|
|
unsigned cores_per_socket;
|
2014-04-23 15:42:42 +02:00
|
|
|
|
2022-10-11 13:17:27 +02:00
|
|
|
if (smbios_ep_type == SMBIOS_ENTRY_POINT_TYPE_64) {
|
|
|
|
tbl_len = SMBIOS_TYPE_4_LEN_V30;
|
|
|
|
}
|
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_PRE_SIZE(4, T4_BASE + instance,
|
|
|
|
true, tbl_len); /* required */
|
2014-04-23 15:42:42 +02:00
|
|
|
|
|
|
|
snprintf(sock_str, sizeof(sock_str), "%s%2x", type4.sock_pfx, instance);
|
|
|
|
SMBIOS_TABLE_SET_STR(4, socket_designation_str, sock_str);
|
|
|
|
t->processor_type = 0x03; /* CPU */
|
2024-01-23 19:42:26 +01:00
|
|
|
t->processor_family = 0xfe; /* use Processor Family 2 field */
|
2014-04-23 15:42:42 +02:00
|
|
|
SMBIOS_TABLE_SET_STR(4, processor_manufacturer_str, type4.manufacturer);
|
2022-01-25 17:31:18 +01:00
|
|
|
if (type4.processor_id == 0) {
|
|
|
|
t->processor_id[0] = cpu_to_le32(smbios_cpuid_version);
|
|
|
|
t->processor_id[1] = cpu_to_le32(smbios_cpuid_features);
|
|
|
|
} else {
|
|
|
|
t->processor_id[0] = cpu_to_le32((uint32_t)type4.processor_id);
|
|
|
|
t->processor_id[1] = cpu_to_le32(type4.processor_id >> 32);
|
|
|
|
}
|
2014-04-23 15:42:42 +02:00
|
|
|
SMBIOS_TABLE_SET_STR(4, processor_version_str, type4.version);
|
|
|
|
t->voltage = 0;
|
2014-05-19 16:09:53 +02:00
|
|
|
t->external_clock = cpu_to_le16(0); /* Unknown */
|
2020-08-06 05:56:33 +02:00
|
|
|
t->max_speed = cpu_to_le16(type4.max_speed);
|
|
|
|
t->current_speed = cpu_to_le16(type4.current_speed);
|
2014-04-23 15:42:42 +02:00
|
|
|
t->status = 0x41; /* Socket populated, CPU enabled */
|
|
|
|
t->processor_upgrade = 0x01; /* Other */
|
2014-05-19 16:09:53 +02:00
|
|
|
t->l1_cache_handle = cpu_to_le16(0xFFFF); /* N/A */
|
|
|
|
t->l2_cache_handle = cpu_to_le16(0xFFFF); /* N/A */
|
|
|
|
t->l3_cache_handle = cpu_to_le16(0xFFFF); /* N/A */
|
2014-04-23 15:42:42 +02:00
|
|
|
SMBIOS_TABLE_SET_STR(4, serial_number_str, type4.serial);
|
|
|
|
SMBIOS_TABLE_SET_STR(4, asset_tag_number_str, type4.asset);
|
|
|
|
SMBIOS_TABLE_SET_STR(4, part_number_str, type4.part);
|
2022-10-11 13:17:27 +02:00
|
|
|
|
2023-06-28 15:54:36 +02:00
|
|
|
threads_per_socket = machine_topo_get_threads_per_socket(ms);
|
2023-06-28 15:54:37 +02:00
|
|
|
cores_per_socket = machine_topo_get_cores_per_socket(ms);
|
2023-06-28 15:54:36 +02:00
|
|
|
|
2023-06-28 15:54:37 +02:00
|
|
|
t->core_count = (cores_per_socket > 255) ? 0xFF : cores_per_socket;
|
2022-10-11 13:17:27 +02:00
|
|
|
t->core_enabled = t->core_count;
|
|
|
|
|
2023-06-28 15:54:36 +02:00
|
|
|
t->thread_count = (threads_per_socket > 255) ? 0xFF : threads_per_socket;
|
2022-10-11 13:17:27 +02:00
|
|
|
|
2014-05-19 16:09:53 +02:00
|
|
|
t->processor_characteristics = cpu_to_le16(0x02); /* Unknown */
|
2024-01-23 19:42:26 +01:00
|
|
|
t->processor_family2 = cpu_to_le16(type4.processor_family);
|
2014-04-23 15:42:42 +02:00
|
|
|
|
2023-02-23 13:57:47 +01:00
|
|
|
if (tbl_len == SMBIOS_TYPE_4_LEN_V30) {
|
2023-06-28 15:54:37 +02:00
|
|
|
t->core_count2 = t->core_enabled2 = cpu_to_le16(cores_per_socket);
|
2023-06-28 15:54:36 +02:00
|
|
|
t->thread_count2 = cpu_to_le16(threads_per_socket);
|
2023-02-23 13:57:47 +01:00
|
|
|
}
|
|
|
|
|
2014-04-23 15:42:42 +02:00
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
smbios_type4_count++;
|
|
|
|
}
|
|
|
|
|
hw/smbios: support for type 8 (port connector)
PATCH v1: add support for SMBIOS type 8 to qemu
PATCH v2: incorporate patch v1 feedback and add smbios type=8 to qemu-options
internal_reference: internal reference designator
external_reference: external reference designator
connector_type: hex value for port connector type (see SMBIOS 7.9.2)
port_type: hex value for port type (see SMBIOS 7.9.3)
After studying various vendor implementationsi (Dell, Lenovo, MSI),
the value of internal connector type was hard-coded to 0x0 (None).
Example usage:
-smbios type=8,internal_reference=JUSB1,external_reference=USB1,connector_type=0x12,port_type=0x10 \
-smbios type=8,internal_reference=JAUD1,external_reference="Audio Jack",connector_type=0x1f,port_type=0x1d \
-smbios type=8,internal_reference=LAN,external_reference=Ethernet,connector_type=0x0b,port_type=0x1f \
-smbios type=8,internal_reference=PS2,external_reference=Mouse,connector_type=0x0f,port_type=0x0e \
-smbios type=8,internal_reference=PS2,external_reference=Keyboard,connector_type=0x0f,port_type=0x0d
Signed-off-by: Hal Martin <hal.martin@gmail.com>
Message-Id: <20220812135153.17859-1-hal.martin@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-08-12 15:51:53 +02:00
|
|
|
static void smbios_build_type_8_table(void)
|
|
|
|
{
|
|
|
|
unsigned instance = 0;
|
|
|
|
struct type8_instance *t8;
|
|
|
|
|
|
|
|
QTAILQ_FOREACH(t8, &type8, next) {
|
|
|
|
SMBIOS_BUILD_TABLE_PRE(8, T0_BASE + instance, true);
|
|
|
|
|
|
|
|
SMBIOS_TABLE_SET_STR(8, internal_reference_str, t8->internal_reference);
|
|
|
|
SMBIOS_TABLE_SET_STR(8, external_reference_str, t8->external_reference);
|
|
|
|
/* most vendors seem to set this to None */
|
|
|
|
t->internal_connector_type = 0x0;
|
|
|
|
t->external_connector_type = t8->connector_type;
|
|
|
|
t->port_type = t8->port_type;
|
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
instance++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
static void smbios_build_type_11_table(void)
|
|
|
|
{
|
|
|
|
char count_str[128];
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
if (type11.nvalues == 0) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2022-02-23 15:33:20 +01:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(11, T11_BASE, true); /* required */
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
|
|
|
|
snprintf(count_str, sizeof(count_str), "%zu", type11.nvalues);
|
|
|
|
t->count = type11.nvalues;
|
|
|
|
|
|
|
|
for (i = 0; i < type11.nvalues; i++) {
|
|
|
|
SMBIOS_TABLE_SET_STR_LIST(11, type11.values[i]);
|
2020-09-23 15:38:02 +02:00
|
|
|
g_free(type11.values[i]);
|
|
|
|
type11.values[i] = NULL;
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
}
|
|
|
|
|
2014-04-23 15:42:42 +02:00
|
|
|
#define MAX_T16_STD_SZ 0x80000000 /* 2T in Kilobytes */
|
|
|
|
|
|
|
|
static void smbios_build_type_16_table(unsigned dimm_cnt)
|
|
|
|
{
|
2014-11-05 07:19:54 +01:00
|
|
|
uint64_t size_kb;
|
2014-04-23 15:42:42 +02:00
|
|
|
|
2022-02-23 15:33:20 +01:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(16, T16_BASE, true); /* required */
|
2014-04-23 15:42:42 +02:00
|
|
|
|
|
|
|
t->location = 0x01; /* Other */
|
|
|
|
t->use = 0x03; /* System memory */
|
|
|
|
t->error_correction = 0x06; /* Multi-bit ECC (for Microsoft, per SeaBIOS) */
|
2020-10-28 11:22:23 +01:00
|
|
|
size_kb = QEMU_ALIGN_UP(current_machine->ram_size, KiB) / KiB;
|
2014-04-23 15:42:42 +02:00
|
|
|
if (size_kb < MAX_T16_STD_SZ) {
|
2014-05-19 16:09:53 +02:00
|
|
|
t->maximum_capacity = cpu_to_le32(size_kb);
|
|
|
|
t->extended_maximum_capacity = cpu_to_le64(0);
|
2014-04-23 15:42:42 +02:00
|
|
|
} else {
|
2014-05-19 16:09:53 +02:00
|
|
|
t->maximum_capacity = cpu_to_le32(MAX_T16_STD_SZ);
|
2020-10-28 11:22:23 +01:00
|
|
|
t->extended_maximum_capacity = cpu_to_le64(current_machine->ram_size);
|
2014-04-23 15:42:42 +02:00
|
|
|
}
|
2014-05-19 16:09:53 +02:00
|
|
|
t->memory_error_information_handle = cpu_to_le16(0xFFFE); /* Not provided */
|
|
|
|
t->number_of_memory_devices = cpu_to_le16(dimm_cnt);
|
2014-04-23 15:42:42 +02:00
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define MAX_T17_STD_SZ 0x7FFF /* (32G - 1M), in Megabytes */
|
|
|
|
#define MAX_T17_EXT_SZ 0x80000000 /* 2P, in Megabytes */
|
|
|
|
|
2014-11-05 07:19:54 +01:00
|
|
|
static void smbios_build_type_17_table(unsigned instance, uint64_t size)
|
2014-04-23 15:42:42 +02:00
|
|
|
{
|
|
|
|
char loc_str[128];
|
2014-11-05 07:19:54 +01:00
|
|
|
uint64_t size_mb;
|
2014-04-23 15:42:42 +02:00
|
|
|
|
2022-02-23 15:33:20 +01:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(17, T17_BASE + instance, true); /* required */
|
2014-04-23 15:42:42 +02:00
|
|
|
|
2014-05-19 16:09:53 +02:00
|
|
|
t->physical_memory_array_handle = cpu_to_le16(0x1000); /* Type 16 above */
|
|
|
|
t->memory_error_information_handle = cpu_to_le16(0xFFFE); /* Not provided */
|
|
|
|
t->total_width = cpu_to_le16(0xFFFF); /* Unknown */
|
|
|
|
t->data_width = cpu_to_le16(0xFFFF); /* Unknown */
|
2018-06-25 14:42:02 +02:00
|
|
|
size_mb = QEMU_ALIGN_UP(size, MiB) / MiB;
|
2014-04-23 15:42:42 +02:00
|
|
|
if (size_mb < MAX_T17_STD_SZ) {
|
2014-05-19 16:09:53 +02:00
|
|
|
t->size = cpu_to_le16(size_mb);
|
|
|
|
t->extended_size = cpu_to_le32(0);
|
2014-04-23 15:42:42 +02:00
|
|
|
} else {
|
|
|
|
assert(size_mb < MAX_T17_EXT_SZ);
|
2014-05-19 16:09:53 +02:00
|
|
|
t->size = cpu_to_le16(MAX_T17_STD_SZ);
|
|
|
|
t->extended_size = cpu_to_le32(size_mb);
|
2014-04-23 15:42:42 +02:00
|
|
|
}
|
|
|
|
t->form_factor = 0x09; /* DIMM */
|
|
|
|
t->device_set = 0; /* Not in a set */
|
|
|
|
snprintf(loc_str, sizeof(loc_str), "%s %d", type17.loc_pfx, instance);
|
|
|
|
SMBIOS_TABLE_SET_STR(17, device_locator_str, loc_str);
|
|
|
|
SMBIOS_TABLE_SET_STR(17, bank_locator_str, type17.bank);
|
|
|
|
t->memory_type = 0x07; /* RAM */
|
2014-05-19 16:09:53 +02:00
|
|
|
t->type_detail = cpu_to_le16(0x02); /* Other */
|
2015-03-11 18:58:01 +01:00
|
|
|
t->speed = cpu_to_le16(type17.speed);
|
2014-04-23 15:42:42 +02:00
|
|
|
SMBIOS_TABLE_SET_STR(17, manufacturer_str, type17.manufacturer);
|
|
|
|
SMBIOS_TABLE_SET_STR(17, serial_number_str, type17.serial);
|
|
|
|
SMBIOS_TABLE_SET_STR(17, asset_tag_number_str, type17.asset);
|
|
|
|
SMBIOS_TABLE_SET_STR(17, part_number_str, type17.part);
|
|
|
|
t->attributes = 0; /* Unknown */
|
2015-03-11 18:58:01 +01:00
|
|
|
t->configured_clock_speed = t->speed; /* reuse value for max speed */
|
2014-05-19 16:09:55 +02:00
|
|
|
t->minimum_voltage = cpu_to_le16(0); /* Unknown */
|
|
|
|
t->maximum_voltage = cpu_to_le16(0); /* Unknown */
|
|
|
|
t->configured_voltage = cpu_to_le16(0); /* Unknown */
|
2014-04-23 15:42:42 +02:00
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
}
|
|
|
|
|
2022-02-23 15:33:21 +01:00
|
|
|
static void smbios_build_type_19_table(unsigned instance, unsigned offset,
|
2014-11-05 07:19:54 +01:00
|
|
|
uint64_t start, uint64_t size)
|
2014-04-23 15:42:42 +02:00
|
|
|
{
|
2014-11-05 07:19:54 +01:00
|
|
|
uint64_t end, start_kb, end_kb;
|
2014-04-23 15:42:42 +02:00
|
|
|
|
2022-02-23 15:33:21 +01:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(19, T19_BASE + offset + instance,
|
|
|
|
true); /* required */
|
2014-04-23 15:42:42 +02:00
|
|
|
|
|
|
|
end = start + size - 1;
|
|
|
|
assert(end > start);
|
2018-06-25 14:42:02 +02:00
|
|
|
start_kb = start / KiB;
|
|
|
|
end_kb = end / KiB;
|
2014-04-23 15:42:42 +02:00
|
|
|
if (start_kb < UINT32_MAX && end_kb < UINT32_MAX) {
|
2014-05-19 16:09:53 +02:00
|
|
|
t->starting_address = cpu_to_le32(start_kb);
|
|
|
|
t->ending_address = cpu_to_le32(end_kb);
|
|
|
|
t->extended_starting_address =
|
|
|
|
t->extended_ending_address = cpu_to_le64(0);
|
2014-04-23 15:42:42 +02:00
|
|
|
} else {
|
2014-05-19 16:09:53 +02:00
|
|
|
t->starting_address = t->ending_address = cpu_to_le32(UINT32_MAX);
|
|
|
|
t->extended_starting_address = cpu_to_le64(start);
|
|
|
|
t->extended_ending_address = cpu_to_le64(end);
|
2014-04-23 15:42:42 +02:00
|
|
|
}
|
2014-05-19 16:09:53 +02:00
|
|
|
t->memory_array_handle = cpu_to_le16(0x1000); /* Type 16 above */
|
2014-04-23 15:42:42 +02:00
|
|
|
t->partition_width = 1; /* One device per row */
|
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void smbios_build_type_32_table(void)
|
|
|
|
{
|
2022-02-23 15:33:20 +01:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(32, T32_BASE, true); /* required */
|
2014-04-23 15:42:42 +02:00
|
|
|
|
|
|
|
memset(t->reserved, 0, 6);
|
|
|
|
t->boot_status = 0; /* No errors detected */
|
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
}
|
|
|
|
|
hw/smbios: support for type 41 (onboard devices extended information)
Type 41 defines the attributes of devices that are onboard. The
original intent was to imply the BIOS had some level of control over
the enablement of the associated devices.
If network devices are present in this table, by default, udev will
name the corresponding interfaces enoX, X being the instance number.
Without such information, udev will fallback to using the PCI ID and
this usually gives ens3 or ens4. This can be a bit annoying as the
name of the network card may depend on the order of options and may
change if a new PCI device is added earlier on the commande line.
Being able to provide SMBIOS type 41 entry ensure the name of the
interface won't change and helps the user guess the right name without
booting a first time.
This can be invoked with:
$QEMU -netdev user,id=internet
-device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet,id=internet-dev \
-smbios type=41,designation='Onboard LAN',instance=1,kind=ethernet,pcidev=internet-dev
The PCI segment is assumed to be 0. This should hold true for most
cases.
$ dmidecode -t 41
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard LAN
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:09.0
$ ip -brief a
lo UNKNOWN 127.0.0.1/8 ::1/128
eno1 UP 10.0.2.14/24 fec0::5254:ff:fe00:42/64 fe80::5254:ff:fe00:42/64
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
Message-Id: <20210401171138.62970-1-vincent@bernat.ch>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-04-01 19:11:38 +02:00
|
|
|
static void smbios_build_type_41_table(Error **errp)
|
|
|
|
{
|
|
|
|
unsigned instance = 0;
|
|
|
|
struct type41_instance *t41;
|
|
|
|
|
|
|
|
QTAILQ_FOREACH(t41, &type41, next) {
|
2022-02-23 15:33:20 +01:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(41, T41_BASE + instance, true);
|
hw/smbios: support for type 41 (onboard devices extended information)
Type 41 defines the attributes of devices that are onboard. The
original intent was to imply the BIOS had some level of control over
the enablement of the associated devices.
If network devices are present in this table, by default, udev will
name the corresponding interfaces enoX, X being the instance number.
Without such information, udev will fallback to using the PCI ID and
this usually gives ens3 or ens4. This can be a bit annoying as the
name of the network card may depend on the order of options and may
change if a new PCI device is added earlier on the commande line.
Being able to provide SMBIOS type 41 entry ensure the name of the
interface won't change and helps the user guess the right name without
booting a first time.
This can be invoked with:
$QEMU -netdev user,id=internet
-device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet,id=internet-dev \
-smbios type=41,designation='Onboard LAN',instance=1,kind=ethernet,pcidev=internet-dev
The PCI segment is assumed to be 0. This should hold true for most
cases.
$ dmidecode -t 41
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard LAN
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:09.0
$ ip -brief a
lo UNKNOWN 127.0.0.1/8 ::1/128
eno1 UP 10.0.2.14/24 fec0::5254:ff:fe00:42/64 fe80::5254:ff:fe00:42/64
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
Message-Id: <20210401171138.62970-1-vincent@bernat.ch>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-04-01 19:11:38 +02:00
|
|
|
|
|
|
|
SMBIOS_TABLE_SET_STR(41, reference_designation_str, t41->designation);
|
|
|
|
t->device_type = t41->kind;
|
|
|
|
t->device_type_instance = t41->instance;
|
|
|
|
t->segment_group_number = cpu_to_le16(0);
|
|
|
|
t->bus_number = 0;
|
|
|
|
t->device_number = 0;
|
|
|
|
|
|
|
|
if (t41->pcidev) {
|
|
|
|
PCIDevice *pdev = NULL;
|
|
|
|
int rc = pci_qdev_find_device(t41->pcidev, &pdev);
|
|
|
|
if (rc != 0) {
|
|
|
|
error_setg(errp,
|
|
|
|
"No PCI device %s for SMBIOS type 41 entry %s",
|
|
|
|
t41->pcidev, t41->designation);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* We only handle the case were the device is attached to
|
|
|
|
* the PCI root bus. The general case is more complex as
|
|
|
|
* bridges are enumerated later and the table would need
|
|
|
|
* to be updated at this moment.
|
|
|
|
*/
|
|
|
|
if (!pci_bus_is_root(pci_get_bus(pdev))) {
|
|
|
|
error_setg(errp,
|
|
|
|
"Cannot create type 41 entry for PCI device %s: "
|
|
|
|
"not attached to the root bus",
|
|
|
|
t41->pcidev);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
t->segment_group_number = cpu_to_le16(0);
|
|
|
|
t->bus_number = pci_dev_bus_num(pdev);
|
|
|
|
t->device_number = pdev->devfn;
|
|
|
|
}
|
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
instance++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-04-23 15:42:42 +02:00
|
|
|
static void smbios_build_type_127_table(void)
|
|
|
|
{
|
2022-02-23 15:33:20 +01:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(127, T127_BASE, true); /* required */
|
2014-04-23 15:42:42 +02:00
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
}
|
|
|
|
|
|
|
|
void smbios_set_cpuid(uint32_t version, uint32_t features)
|
|
|
|
{
|
|
|
|
smbios_cpuid_version = version;
|
|
|
|
smbios_cpuid_features = features;
|
|
|
|
}
|
|
|
|
|
2014-04-23 15:42:40 +02:00
|
|
|
#define SMBIOS_SET_DEFAULT(field, value) \
|
|
|
|
if (!field) { \
|
|
|
|
field = value; \
|
|
|
|
}
|
|
|
|
|
2024-01-23 19:42:27 +01:00
|
|
|
void smbios_set_default_processor_family(uint16_t processor_family)
|
|
|
|
{
|
|
|
|
if (type4.processor_family <= 0x01) {
|
|
|
|
type4.processor_family = processor_family;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-04-23 15:42:40 +02:00
|
|
|
void smbios_set_defaults(const char *manufacturer, const char *product,
|
smbios: Encode UUID according to SMBIOS specification
Differently from older versions, SMBIOS version 2.6 is explicit about
the encoding of UUID fields:
> Although RFC 4122 recommends network byte order for all fields, the PC
> industry (including the ACPI, UEFI, and Microsoft specifications) has
> consistently used little-endian byte encoding for the first three fields:
> time_low, time_mid, time_hi_and_version. The same encoding, also known as
> wire format, should also be used for the SMBIOS representation of the UUID.
>
> The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented
> as 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.
The dmidecode tool implements this and decodes the above "wire format"
when SMBIOS version >= 2.6. We moved from SMBIOS version 2.4 to 2.8 when
we started building the SMBIOS entry point inside QEMU, on commit
c97294ec1b9e36887e119589d456557d72ab37b5.
Change smbios_build_type_1_table() to encode the UUID as specified.
To make sure we won't change the guest-visible UUID when upgrading to a
newer QEMU version, keep the old behavior on pc-*-2.1 and older.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-10-29 14:26:08 +01:00
|
|
|
const char *version, bool legacy_mode,
|
2015-09-07 11:39:28 +02:00
|
|
|
bool uuid_encoded, SmbiosEntryPointType ep_type)
|
2014-04-23 15:42:40 +02:00
|
|
|
{
|
2014-04-23 15:42:42 +02:00
|
|
|
smbios_have_defaults = true;
|
|
|
|
smbios_legacy = legacy_mode;
|
smbios: Encode UUID according to SMBIOS specification
Differently from older versions, SMBIOS version 2.6 is explicit about
the encoding of UUID fields:
> Although RFC 4122 recommends network byte order for all fields, the PC
> industry (including the ACPI, UEFI, and Microsoft specifications) has
> consistently used little-endian byte encoding for the first three fields:
> time_low, time_mid, time_hi_and_version. The same encoding, also known as
> wire format, should also be used for the SMBIOS representation of the UUID.
>
> The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented
> as 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.
The dmidecode tool implements this and decodes the above "wire format"
when SMBIOS version >= 2.6. We moved from SMBIOS version 2.4 to 2.8 when
we started building the SMBIOS entry point inside QEMU, on commit
c97294ec1b9e36887e119589d456557d72ab37b5.
Change smbios_build_type_1_table() to encode the UUID as specified.
To make sure we won't change the guest-visible UUID when upgrading to a
newer QEMU version, keep the old behavior on pc-*-2.1 and older.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-10-29 14:26:08 +01:00
|
|
|
smbios_uuid_encoded = uuid_encoded;
|
2015-09-07 11:39:28 +02:00
|
|
|
smbios_ep_type = ep_type;
|
2014-04-23 15:42:42 +02:00
|
|
|
|
|
|
|
/* drop unwanted version of command-line file blob(s) */
|
|
|
|
if (smbios_legacy) {
|
2014-06-04 18:00:28 +02:00
|
|
|
g_free(smbios_tables);
|
2014-04-23 15:42:42 +02:00
|
|
|
/* in legacy mode, also complain if fields were given for types > 1 */
|
|
|
|
if (find_next_bit(have_fields_bitmap,
|
|
|
|
SMBIOS_MAX_TYPE+1, 2) < SMBIOS_MAX_TYPE+1) {
|
|
|
|
error_report("can't process fields for smbios "
|
|
|
|
"types > 1 on machine versions < 2.1!");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
} else {
|
2014-06-04 18:00:28 +02:00
|
|
|
g_free(smbios_entries);
|
2014-04-23 15:42:42 +02:00
|
|
|
}
|
|
|
|
|
2014-04-23 15:42:40 +02:00
|
|
|
SMBIOS_SET_DEFAULT(type1.manufacturer, manufacturer);
|
|
|
|
SMBIOS_SET_DEFAULT(type1.product, product);
|
|
|
|
SMBIOS_SET_DEFAULT(type1.version, version);
|
2014-04-23 15:42:42 +02:00
|
|
|
SMBIOS_SET_DEFAULT(type2.manufacturer, manufacturer);
|
|
|
|
SMBIOS_SET_DEFAULT(type2.product, product);
|
|
|
|
SMBIOS_SET_DEFAULT(type2.version, version);
|
|
|
|
SMBIOS_SET_DEFAULT(type3.manufacturer, manufacturer);
|
|
|
|
SMBIOS_SET_DEFAULT(type3.version, version);
|
|
|
|
SMBIOS_SET_DEFAULT(type4.sock_pfx, "CPU");
|
|
|
|
SMBIOS_SET_DEFAULT(type4.manufacturer, manufacturer);
|
|
|
|
SMBIOS_SET_DEFAULT(type4.version, version);
|
|
|
|
SMBIOS_SET_DEFAULT(type17.loc_pfx, "DIMM");
|
|
|
|
SMBIOS_SET_DEFAULT(type17.manufacturer, manufacturer);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void smbios_entry_point_setup(void)
|
|
|
|
{
|
2015-09-07 11:39:28 +02:00
|
|
|
switch (smbios_ep_type) {
|
2021-10-26 17:10:58 +02:00
|
|
|
case SMBIOS_ENTRY_POINT_TYPE_32:
|
2015-09-07 11:39:28 +02:00
|
|
|
memcpy(ep.ep21.anchor_string, "_SM_", 4);
|
|
|
|
memcpy(ep.ep21.intermediate_anchor_string, "_DMI_", 5);
|
|
|
|
ep.ep21.length = sizeof(struct smbios_21_entry_point);
|
|
|
|
ep.ep21.entry_point_revision = 0; /* formatted_area reserved */
|
|
|
|
memset(ep.ep21.formatted_area, 0, 5);
|
|
|
|
|
|
|
|
/* compliant with smbios spec v2.8 */
|
|
|
|
ep.ep21.smbios_major_version = 2;
|
|
|
|
ep.ep21.smbios_minor_version = 8;
|
|
|
|
ep.ep21.smbios_bcd_revision = 0x28;
|
|
|
|
|
|
|
|
/* set during table construction, but BIOS may override: */
|
|
|
|
ep.ep21.structure_table_length = cpu_to_le16(smbios_tables_len);
|
|
|
|
ep.ep21.max_structure_size = cpu_to_le16(smbios_table_max);
|
|
|
|
ep.ep21.number_of_structures = cpu_to_le16(smbios_table_cnt);
|
|
|
|
|
|
|
|
/* BIOS must recalculate */
|
|
|
|
ep.ep21.checksum = 0;
|
|
|
|
ep.ep21.intermediate_checksum = 0;
|
|
|
|
ep.ep21.structure_table_address = cpu_to_le32(0);
|
|
|
|
|
|
|
|
break;
|
2021-10-26 17:10:58 +02:00
|
|
|
case SMBIOS_ENTRY_POINT_TYPE_64:
|
2015-09-07 11:39:28 +02:00
|
|
|
memcpy(ep.ep30.anchor_string, "_SM3_", 5);
|
|
|
|
ep.ep30.length = sizeof(struct smbios_30_entry_point);
|
|
|
|
ep.ep30.entry_point_revision = 1;
|
|
|
|
ep.ep30.reserved = 0;
|
|
|
|
|
|
|
|
/* compliant with smbios spec 3.0 */
|
|
|
|
ep.ep30.smbios_major_version = 3;
|
|
|
|
ep.ep30.smbios_minor_version = 0;
|
|
|
|
ep.ep30.smbios_doc_rev = 0;
|
|
|
|
|
|
|
|
/* set during table construct, but BIOS might override */
|
|
|
|
ep.ep30.structure_table_max_size = cpu_to_le32(smbios_tables_len);
|
|
|
|
|
|
|
|
/* BIOS must recalculate */
|
|
|
|
ep.ep30.checksum = 0;
|
|
|
|
ep.ep30.structure_table_address = cpu_to_le64(0);
|
|
|
|
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
abort();
|
|
|
|
break;
|
|
|
|
}
|
2014-04-23 15:42:42 +02:00
|
|
|
}
|
|
|
|
|
2019-05-18 22:54:20 +02:00
|
|
|
void smbios_get_tables(MachineState *ms,
|
|
|
|
const struct smbios_phys_mem_area *mem_array,
|
2015-08-12 04:08:19 +02:00
|
|
|
const unsigned int mem_array_size,
|
|
|
|
uint8_t **tables, size_t *tables_len,
|
hw/smbios: support for type 41 (onboard devices extended information)
Type 41 defines the attributes of devices that are onboard. The
original intent was to imply the BIOS had some level of control over
the enablement of the associated devices.
If network devices are present in this table, by default, udev will
name the corresponding interfaces enoX, X being the instance number.
Without such information, udev will fallback to using the PCI ID and
this usually gives ens3 or ens4. This can be a bit annoying as the
name of the network card may depend on the order of options and may
change if a new PCI device is added earlier on the commande line.
Being able to provide SMBIOS type 41 entry ensure the name of the
interface won't change and helps the user guess the right name without
booting a first time.
This can be invoked with:
$QEMU -netdev user,id=internet
-device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet,id=internet-dev \
-smbios type=41,designation='Onboard LAN',instance=1,kind=ethernet,pcidev=internet-dev
The PCI segment is assumed to be 0. This should hold true for most
cases.
$ dmidecode -t 41
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard LAN
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:09.0
$ ip -brief a
lo UNKNOWN 127.0.0.1/8 ::1/128
eno1 UP 10.0.2.14/24 fec0::5254:ff:fe00:42/64 fe80::5254:ff:fe00:42/64
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
Message-Id: <20210401171138.62970-1-vincent@bernat.ch>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-04-01 19:11:38 +02:00
|
|
|
uint8_t **anchor, size_t *anchor_len,
|
|
|
|
Error **errp)
|
2014-04-23 15:42:42 +02:00
|
|
|
{
|
2022-02-23 15:33:21 +01:00
|
|
|
unsigned i, dimm_cnt, offset;
|
2014-04-23 15:42:42 +02:00
|
|
|
|
|
|
|
if (smbios_legacy) {
|
|
|
|
*tables = *anchor = NULL;
|
|
|
|
*tables_len = *anchor_len = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!smbios_immutable) {
|
|
|
|
smbios_build_type_0_table();
|
|
|
|
smbios_build_type_1_table();
|
|
|
|
smbios_build_type_2_table();
|
|
|
|
smbios_build_type_3_table();
|
|
|
|
|
2023-06-28 15:54:35 +02:00
|
|
|
smbios_smp_sockets = ms->smp.sockets;
|
2014-04-23 15:42:42 +02:00
|
|
|
assert(smbios_smp_sockets >= 1);
|
|
|
|
|
|
|
|
for (i = 0; i < smbios_smp_sockets; i++) {
|
2019-05-18 22:54:20 +02:00
|
|
|
smbios_build_type_4_table(ms, i);
|
2014-04-23 15:42:42 +02:00
|
|
|
}
|
|
|
|
|
hw/smbios: support for type 8 (port connector)
PATCH v1: add support for SMBIOS type 8 to qemu
PATCH v2: incorporate patch v1 feedback and add smbios type=8 to qemu-options
internal_reference: internal reference designator
external_reference: external reference designator
connector_type: hex value for port connector type (see SMBIOS 7.9.2)
port_type: hex value for port type (see SMBIOS 7.9.3)
After studying various vendor implementationsi (Dell, Lenovo, MSI),
the value of internal connector type was hard-coded to 0x0 (None).
Example usage:
-smbios type=8,internal_reference=JUSB1,external_reference=USB1,connector_type=0x12,port_type=0x10 \
-smbios type=8,internal_reference=JAUD1,external_reference="Audio Jack",connector_type=0x1f,port_type=0x1d \
-smbios type=8,internal_reference=LAN,external_reference=Ethernet,connector_type=0x0b,port_type=0x1f \
-smbios type=8,internal_reference=PS2,external_reference=Mouse,connector_type=0x0f,port_type=0x0e \
-smbios type=8,internal_reference=PS2,external_reference=Keyboard,connector_type=0x0f,port_type=0x0d
Signed-off-by: Hal Martin <hal.martin@gmail.com>
Message-Id: <20220812135153.17859-1-hal.martin@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-08-12 15:51:53 +02:00
|
|
|
smbios_build_type_8_table();
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
smbios_build_type_11_table();
|
|
|
|
|
2018-06-25 14:42:02 +02:00
|
|
|
#define MAX_DIMM_SZ (16 * GiB)
|
2015-01-07 18:36:33 +01:00
|
|
|
#define GET_DIMM_SZ ((i < dimm_cnt - 1) ? MAX_DIMM_SZ \
|
2020-10-28 11:22:23 +01:00
|
|
|
: ((current_machine->ram_size - 1) % MAX_DIMM_SZ) + 1)
|
2014-04-23 15:42:42 +02:00
|
|
|
|
2020-10-28 11:22:23 +01:00
|
|
|
dimm_cnt = QEMU_ALIGN_UP(current_machine->ram_size, MAX_DIMM_SZ) / MAX_DIMM_SZ;
|
2014-04-23 15:42:42 +02:00
|
|
|
|
2022-02-23 15:33:21 +01:00
|
|
|
/*
|
2023-07-14 13:32:24 +02:00
|
|
|
* The offset determines if we need to keep additional space between
|
2022-02-23 15:33:21 +01:00
|
|
|
* table 17 and table 19 header handle numbers so that they do
|
|
|
|
* not overlap. For example, for a VM with larger than 8 TB guest
|
|
|
|
* memory and DIMM like chunks of 16 GiB, the default space between
|
|
|
|
* the two tables (T19_BASE - T17_BASE = 512) is not enough.
|
|
|
|
*/
|
|
|
|
offset = (dimm_cnt > (T19_BASE - T17_BASE)) ? \
|
|
|
|
dimm_cnt - (T19_BASE - T17_BASE) : 0;
|
|
|
|
|
2014-04-23 15:42:42 +02:00
|
|
|
smbios_build_type_16_table(dimm_cnt);
|
|
|
|
|
|
|
|
for (i = 0; i < dimm_cnt; i++) {
|
|
|
|
smbios_build_type_17_table(i, GET_DIMM_SZ);
|
|
|
|
}
|
|
|
|
|
2015-08-12 04:08:19 +02:00
|
|
|
for (i = 0; i < mem_array_size; i++) {
|
2022-02-23 15:33:21 +01:00
|
|
|
smbios_build_type_19_table(i, offset, mem_array[i].address,
|
2015-08-12 04:08:19 +02:00
|
|
|
mem_array[i].length);
|
2014-04-23 15:42:42 +02:00
|
|
|
}
|
|
|
|
|
2022-02-23 15:33:22 +01:00
|
|
|
/*
|
|
|
|
* make sure 16 bit handle numbers in the headers of tables 19
|
|
|
|
* and 32 do not overlap.
|
|
|
|
*/
|
|
|
|
assert((mem_array_size + offset) < (T32_BASE - T19_BASE));
|
|
|
|
|
2014-04-23 15:42:42 +02:00
|
|
|
smbios_build_type_32_table();
|
2016-06-10 11:15:41 +02:00
|
|
|
smbios_build_type_38_table();
|
hw/smbios: support for type 41 (onboard devices extended information)
Type 41 defines the attributes of devices that are onboard. The
original intent was to imply the BIOS had some level of control over
the enablement of the associated devices.
If network devices are present in this table, by default, udev will
name the corresponding interfaces enoX, X being the instance number.
Without such information, udev will fallback to using the PCI ID and
this usually gives ens3 or ens4. This can be a bit annoying as the
name of the network card may depend on the order of options and may
change if a new PCI device is added earlier on the commande line.
Being able to provide SMBIOS type 41 entry ensure the name of the
interface won't change and helps the user guess the right name without
booting a first time.
This can be invoked with:
$QEMU -netdev user,id=internet
-device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet,id=internet-dev \
-smbios type=41,designation='Onboard LAN',instance=1,kind=ethernet,pcidev=internet-dev
The PCI segment is assumed to be 0. This should hold true for most
cases.
$ dmidecode -t 41
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard LAN
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:09.0
$ ip -brief a
lo UNKNOWN 127.0.0.1/8 ::1/128
eno1 UP 10.0.2.14/24 fec0::5254:ff:fe00:42/64 fe80::5254:ff:fe00:42/64
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
Message-Id: <20210401171138.62970-1-vincent@bernat.ch>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-04-01 19:11:38 +02:00
|
|
|
smbios_build_type_41_table(errp);
|
2014-04-23 15:42:42 +02:00
|
|
|
smbios_build_type_127_table();
|
|
|
|
|
2019-05-18 22:54:20 +02:00
|
|
|
smbios_validate_table(ms);
|
2014-04-23 15:42:42 +02:00
|
|
|
smbios_entry_point_setup();
|
|
|
|
smbios_immutable = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* return tables blob and entry point (anchor), and their sizes */
|
|
|
|
*tables = smbios_tables;
|
|
|
|
*tables_len = smbios_tables_len;
|
|
|
|
*anchor = (uint8_t *)&ep;
|
2015-09-07 11:39:28 +02:00
|
|
|
|
|
|
|
/* calculate length based on anchor string */
|
|
|
|
if (!strncmp((char *)&ep, "_SM_", 4)) {
|
|
|
|
*anchor_len = sizeof(struct smbios_21_entry_point);
|
|
|
|
} else if (!strncmp((char *)&ep, "_SM3_", 5)) {
|
|
|
|
*anchor_len = sizeof(struct smbios_30_entry_point);
|
|
|
|
} else {
|
|
|
|
abort();
|
|
|
|
}
|
2014-04-23 15:42:40 +02:00
|
|
|
}
|
|
|
|
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
static void save_opt(const char **dest, QemuOpts *opts, const char *name)
|
|
|
|
{
|
|
|
|
const char *val = qemu_opt_get(opts, name);
|
|
|
|
|
|
|
|
if (val) {
|
|
|
|
*dest = val;
|
2013-08-16 15:18:29 +02:00
|
|
|
}
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
}
|
|
|
|
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
|
|
|
|
struct opt_list {
|
|
|
|
size_t *ndest;
|
2020-09-23 15:38:02 +02:00
|
|
|
char ***dest;
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
static int save_opt_one(void *opaque,
|
|
|
|
const char *name, const char *value,
|
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
struct opt_list *opt = opaque;
|
|
|
|
|
2020-09-23 15:38:02 +02:00
|
|
|
if (g_str_equal(name, "path")) {
|
|
|
|
g_autoptr(GByteArray) data = g_byte_array_new();
|
|
|
|
g_autofree char *buf = g_new(char, 4096);
|
|
|
|
ssize_t ret;
|
|
|
|
int fd = qemu_open(value, O_RDONLY, errp);
|
|
|
|
if (fd < 0) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
ret = read(fd, buf, 4096);
|
|
|
|
if (ret == 0) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (ret < 0) {
|
|
|
|
error_setg(errp, "Unable to read from %s: %s",
|
|
|
|
value, strerror(errno));
|
2020-10-30 16:27:42 +01:00
|
|
|
qemu_close(fd);
|
2020-09-23 15:38:02 +02:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (memchr(buf, '\0', ret)) {
|
|
|
|
error_setg(errp, "NUL in OEM strings value in %s", value);
|
2020-10-30 16:27:42 +01:00
|
|
|
qemu_close(fd);
|
2020-09-23 15:38:02 +02:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
g_byte_array_append(data, (guint8 *)buf, ret);
|
|
|
|
}
|
|
|
|
|
2020-10-30 16:27:42 +01:00
|
|
|
qemu_close(fd);
|
2020-09-23 15:38:02 +02:00
|
|
|
|
|
|
|
*opt->dest = g_renew(char *, *opt->dest, (*opt->ndest) + 1);
|
|
|
|
(*opt->dest)[*opt->ndest] = (char *)g_byte_array_free(data, FALSE);
|
|
|
|
(*opt->ndest)++;
|
|
|
|
data = NULL;
|
|
|
|
} else if (g_str_equal(name, "value")) {
|
|
|
|
*opt->dest = g_renew(char *, *opt->dest, (*opt->ndest) + 1);
|
|
|
|
(*opt->dest)[*opt->ndest] = g_strdup(value);
|
|
|
|
(*opt->ndest)++;
|
|
|
|
} else if (!g_str_equal(name, "type")) {
|
|
|
|
error_setg(errp, "Unexpected option %s", name);
|
|
|
|
return -1;
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-09-23 15:38:02 +02:00
|
|
|
static bool save_opt_list(size_t *ndest, char ***dest, QemuOpts *opts,
|
|
|
|
Error **errp)
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
{
|
|
|
|
struct opt_list opt = {
|
2020-09-23 15:38:02 +02:00
|
|
|
ndest, dest,
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
};
|
2020-09-23 15:38:02 +02:00
|
|
|
if (!qemu_opt_foreach(opts, save_opt_one, &opt, errp)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
}
|
|
|
|
|
2016-12-22 16:18:28 +01:00
|
|
|
void smbios_entry_add(QemuOpts *opts, Error **errp)
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
{
|
2013-08-16 15:18:29 +02:00
|
|
|
const char *val;
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
assert(!smbios_immutable);
|
2014-04-23 15:42:42 +02:00
|
|
|
|
2013-08-16 15:18:29 +02:00
|
|
|
val = qemu_opt_get(opts, "file");
|
|
|
|
if (val) {
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
struct smbios_structure_header *header;
|
2013-08-16 15:18:29 +02:00
|
|
|
int size;
|
2014-04-23 15:42:42 +02:00
|
|
|
struct smbios_table *table; /* legacy mode only */
|
2013-08-16 15:18:29 +02:00
|
|
|
|
error: Eliminate error_propagate() with Coccinelle, part 1
When all we do with an Error we receive into a local variable is
propagating to somewhere else, we can just as well receive it there
right away. Convert
if (!foo(..., &err)) {
...
error_propagate(errp, err);
...
return ...
}
to
if (!foo(..., errp)) {
...
...
return ...
}
where nothing else needs @err. Coccinelle script:
@rule1 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
binary operator op;
constant c1, c2;
symbol false;
@@
if (
(
- fun(args, &err, args2)
+ fun(args, errp, args2)
|
- !fun(args, &err, args2)
+ !fun(args, errp, args2)
|
- fun(args, &err, args2) op c1
+ fun(args, errp, args2) op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
)
}
@rule2 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
expression var;
binary operator op;
constant c1, c2;
symbol false;
@@
- var = fun(args, &err, args2);
+ var = fun(args, errp, args2);
... when != err
if (
(
var
|
!var
|
var op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
|
return var;
)
}
@depends on rule1 || rule2@
identifier err;
@@
- Error *err = NULL;
... when != err
Not exactly elegant, I'm afraid.
The "when != lbl:" is necessary to avoid transforming
if (fun(args, &err)) {
goto out
}
...
out:
error_propagate(errp, err);
even though other paths to label out still need the error_propagate().
For an actual example, see sclp_realize().
Without the "when strict", Coccinelle transforms vfio_msix_setup(),
incorrectly. I don't know what exactly "when strict" does, only that
it helps here.
The match of return is narrower than what I want, but I can't figure
out how to express "return where the operand doesn't use @err". For
an example where it's too narrow, see vfio_intx_enable().
Silently fails to convert hw/arm/armsse.c, because Coccinelle gets
confused by ARMSSE being used both as typedef and function-like macro
there. Converted manually.
Line breaks tidied up manually. One nested declaration of @local_err
deleted manually. Preexisting unwanted blank line dropped in
hw/riscv/sifive_e.c.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-35-armbru@redhat.com>
2020-07-07 18:06:02 +02:00
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_file_opts, errp)) {
|
2018-10-17 10:26:35 +02:00
|
|
|
return;
|
|
|
|
}
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
|
2013-08-16 15:18:29 +02:00
|
|
|
size = get_image_size(val);
|
2009-07-31 19:49:14 +02:00
|
|
|
if (size == -1 || size < sizeof(struct smbios_structure_header)) {
|
2018-10-17 10:26:35 +02:00
|
|
|
error_setg(errp, "Cannot read SMBIOS file %s", val);
|
|
|
|
return;
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
}
|
|
|
|
|
2014-04-23 15:42:42 +02:00
|
|
|
/*
|
|
|
|
* NOTE: standard double '\0' terminator expected, per smbios spec.
|
|
|
|
* (except in legacy mode, where the second '\0' is implicit and
|
|
|
|
* will be inserted by the BIOS).
|
|
|
|
*/
|
|
|
|
smbios_tables = g_realloc(smbios_tables, smbios_tables_len + size);
|
|
|
|
header = (struct smbios_structure_header *)(smbios_tables +
|
|
|
|
smbios_tables_len);
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
|
2018-12-14 14:30:50 +01:00
|
|
|
if (load_image_size(val, (uint8_t *)header, size) != size) {
|
2018-10-17 10:26:35 +02:00
|
|
|
error_setg(errp, "Failed to load SMBIOS file %s", val);
|
|
|
|
return;
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
}
|
|
|
|
|
2022-09-05 12:32:44 +02:00
|
|
|
if (header->type <= SMBIOS_MAX_TYPE) {
|
|
|
|
if (test_bit(header->type, have_fields_bitmap)) {
|
|
|
|
error_setg(errp,
|
|
|
|
"can't load type %d struct, fields already specified!",
|
|
|
|
header->type);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
set_bit(header->type, have_binfile_bitmap);
|
2014-04-23 15:42:41 +02:00
|
|
|
}
|
|
|
|
|
2009-07-31 19:49:14 +02:00
|
|
|
if (header->type == 4) {
|
|
|
|
smbios_type4_count++;
|
|
|
|
}
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
|
2014-04-23 15:42:42 +02:00
|
|
|
smbios_tables_len += size;
|
|
|
|
if (size > smbios_table_max) {
|
|
|
|
smbios_table_max = size;
|
|
|
|
}
|
|
|
|
smbios_table_cnt++;
|
|
|
|
|
|
|
|
/* add a copy of the newly loaded blob to legacy smbios_entries */
|
|
|
|
/* NOTE: This code runs before smbios_set_defaults(), so we don't
|
|
|
|
* yet know which mode (legacy vs. aggregate-table) will be
|
|
|
|
* required. We therefore add the binary blob to both legacy
|
|
|
|
* (smbios_entries) and aggregate (smbios_tables) tables, and
|
|
|
|
* delete the one we don't need from smbios_set_defaults(),
|
|
|
|
* once we know which machine version has been requested.
|
|
|
|
*/
|
|
|
|
if (!smbios_entries) {
|
|
|
|
smbios_entries_len = sizeof(uint16_t);
|
|
|
|
smbios_entries = g_malloc0(smbios_entries_len);
|
|
|
|
}
|
|
|
|
smbios_entries = g_realloc(smbios_entries, smbios_entries_len +
|
|
|
|
size + sizeof(*table));
|
|
|
|
table = (struct smbios_table *)(smbios_entries + smbios_entries_len);
|
|
|
|
table->header.type = SMBIOS_TABLE_ENTRY;
|
|
|
|
table->header.length = cpu_to_le16(sizeof(*table) + size);
|
|
|
|
memcpy(table->data, header, size);
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
smbios_entries_len += sizeof(*table) + size;
|
|
|
|
(*(uint16_t *)smbios_entries) =
|
|
|
|
cpu_to_le16(le16_to_cpu(*(uint16_t *)smbios_entries) + 1);
|
2014-04-23 15:42:42 +02:00
|
|
|
/* end: add a copy of the newly loaded blob to legacy smbios_entries */
|
|
|
|
|
2013-08-16 15:18:28 +02:00
|
|
|
return;
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
}
|
|
|
|
|
2013-08-16 15:18:29 +02:00
|
|
|
val = qemu_opt_get(opts, "type");
|
|
|
|
if (val) {
|
|
|
|
unsigned long type = strtoul(val, NULL, 0);
|
|
|
|
|
2014-04-23 15:42:41 +02:00
|
|
|
if (type > SMBIOS_MAX_TYPE) {
|
2018-10-17 10:26:35 +02:00
|
|
|
error_setg(errp, "out of range!");
|
|
|
|
return;
|
2014-04-23 15:42:41 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (test_bit(type, have_binfile_bitmap)) {
|
2018-10-17 10:26:35 +02:00
|
|
|
error_setg(errp, "can't add fields, binary file already loaded!");
|
|
|
|
return;
|
2014-04-23 15:42:41 +02:00
|
|
|
}
|
|
|
|
set_bit(type, have_fields_bitmap);
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
switch (type) {
|
|
|
|
case 0:
|
error: Eliminate error_propagate() with Coccinelle, part 1
When all we do with an Error we receive into a local variable is
propagating to somewhere else, we can just as well receive it there
right away. Convert
if (!foo(..., &err)) {
...
error_propagate(errp, err);
...
return ...
}
to
if (!foo(..., errp)) {
...
...
return ...
}
where nothing else needs @err. Coccinelle script:
@rule1 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
binary operator op;
constant c1, c2;
symbol false;
@@
if (
(
- fun(args, &err, args2)
+ fun(args, errp, args2)
|
- !fun(args, &err, args2)
+ !fun(args, errp, args2)
|
- fun(args, &err, args2) op c1
+ fun(args, errp, args2) op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
)
}
@rule2 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
expression var;
binary operator op;
constant c1, c2;
symbol false;
@@
- var = fun(args, &err, args2);
+ var = fun(args, errp, args2);
... when != err
if (
(
var
|
!var
|
var op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
|
return var;
)
}
@depends on rule1 || rule2@
identifier err;
@@
- Error *err = NULL;
... when != err
Not exactly elegant, I'm afraid.
The "when != lbl:" is necessary to avoid transforming
if (fun(args, &err)) {
goto out
}
...
out:
error_propagate(errp, err);
even though other paths to label out still need the error_propagate().
For an actual example, see sclp_realize().
Without the "when strict", Coccinelle transforms vfio_msix_setup(),
incorrectly. I don't know what exactly "when strict" does, only that
it helps here.
The match of return is narrower than what I want, but I can't figure
out how to express "return where the operand doesn't use @err". For
an example where it's too narrow, see vfio_intx_enable().
Silently fails to convert hw/arm/armsse.c, because Coccinelle gets
confused by ARMSSE being used both as typedef and function-like macro
there. Converted manually.
Line breaks tidied up manually. One nested declaration of @local_err
deleted manually. Preexisting unwanted blank line dropped in
hw/riscv/sifive_e.c.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-35-armbru@redhat.com>
2020-07-07 18:06:02 +02:00
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type0_opts, errp)) {
|
2018-10-17 10:26:35 +02:00
|
|
|
return;
|
|
|
|
}
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
save_opt(&type0.vendor, opts, "vendor");
|
|
|
|
save_opt(&type0.version, opts, "version");
|
|
|
|
save_opt(&type0.date, opts, "date");
|
2014-05-19 16:09:54 +02:00
|
|
|
type0.uefi = qemu_opt_get_bool(opts, "uefi", false);
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
|
|
|
|
val = qemu_opt_get(opts, "release");
|
|
|
|
if (val) {
|
|
|
|
if (sscanf(val, "%hhu.%hhu", &type0.major, &type0.minor) != 2) {
|
2018-10-17 10:26:35 +02:00
|
|
|
error_setg(errp, "Invalid release");
|
|
|
|
return;
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
}
|
|
|
|
type0.have_major_minor = true;
|
|
|
|
}
|
2013-08-16 15:18:28 +02:00
|
|
|
return;
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
case 1:
|
error: Eliminate error_propagate() with Coccinelle, part 1
When all we do with an Error we receive into a local variable is
propagating to somewhere else, we can just as well receive it there
right away. Convert
if (!foo(..., &err)) {
...
error_propagate(errp, err);
...
return ...
}
to
if (!foo(..., errp)) {
...
...
return ...
}
where nothing else needs @err. Coccinelle script:
@rule1 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
binary operator op;
constant c1, c2;
symbol false;
@@
if (
(
- fun(args, &err, args2)
+ fun(args, errp, args2)
|
- !fun(args, &err, args2)
+ !fun(args, errp, args2)
|
- fun(args, &err, args2) op c1
+ fun(args, errp, args2) op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
)
}
@rule2 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
expression var;
binary operator op;
constant c1, c2;
symbol false;
@@
- var = fun(args, &err, args2);
+ var = fun(args, errp, args2);
... when != err
if (
(
var
|
!var
|
var op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
|
return var;
)
}
@depends on rule1 || rule2@
identifier err;
@@
- Error *err = NULL;
... when != err
Not exactly elegant, I'm afraid.
The "when != lbl:" is necessary to avoid transforming
if (fun(args, &err)) {
goto out
}
...
out:
error_propagate(errp, err);
even though other paths to label out still need the error_propagate().
For an actual example, see sclp_realize().
Without the "when strict", Coccinelle transforms vfio_msix_setup(),
incorrectly. I don't know what exactly "when strict" does, only that
it helps here.
The match of return is narrower than what I want, but I can't figure
out how to express "return where the operand doesn't use @err". For
an example where it's too narrow, see vfio_intx_enable().
Silently fails to convert hw/arm/armsse.c, because Coccinelle gets
confused by ARMSSE being used both as typedef and function-like macro
there. Converted manually.
Line breaks tidied up manually. One nested declaration of @local_err
deleted manually. Preexisting unwanted blank line dropped in
hw/riscv/sifive_e.c.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-35-armbru@redhat.com>
2020-07-07 18:06:02 +02:00
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type1_opts, errp)) {
|
2018-10-17 10:26:35 +02:00
|
|
|
return;
|
|
|
|
}
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
save_opt(&type1.manufacturer, opts, "manufacturer");
|
|
|
|
save_opt(&type1.product, opts, "product");
|
|
|
|
save_opt(&type1.version, opts, "version");
|
|
|
|
save_opt(&type1.serial, opts, "serial");
|
|
|
|
save_opt(&type1.sku, opts, "sku");
|
|
|
|
save_opt(&type1.family, opts, "family");
|
|
|
|
|
|
|
|
val = qemu_opt_get(opts, "uuid");
|
|
|
|
if (val) {
|
2016-09-21 06:27:22 +02:00
|
|
|
if (qemu_uuid_parse(val, &qemu_uuid) != 0) {
|
2018-10-17 10:26:35 +02:00
|
|
|
error_setg(errp, "Invalid UUID");
|
|
|
|
return;
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
}
|
|
|
|
qemu_uuid_set = true;
|
|
|
|
}
|
2013-08-16 15:18:28 +02:00
|
|
|
return;
|
2014-04-23 15:42:42 +02:00
|
|
|
case 2:
|
error: Eliminate error_propagate() with Coccinelle, part 1
When all we do with an Error we receive into a local variable is
propagating to somewhere else, we can just as well receive it there
right away. Convert
if (!foo(..., &err)) {
...
error_propagate(errp, err);
...
return ...
}
to
if (!foo(..., errp)) {
...
...
return ...
}
where nothing else needs @err. Coccinelle script:
@rule1 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
binary operator op;
constant c1, c2;
symbol false;
@@
if (
(
- fun(args, &err, args2)
+ fun(args, errp, args2)
|
- !fun(args, &err, args2)
+ !fun(args, errp, args2)
|
- fun(args, &err, args2) op c1
+ fun(args, errp, args2) op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
)
}
@rule2 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
expression var;
binary operator op;
constant c1, c2;
symbol false;
@@
- var = fun(args, &err, args2);
+ var = fun(args, errp, args2);
... when != err
if (
(
var
|
!var
|
var op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
|
return var;
)
}
@depends on rule1 || rule2@
identifier err;
@@
- Error *err = NULL;
... when != err
Not exactly elegant, I'm afraid.
The "when != lbl:" is necessary to avoid transforming
if (fun(args, &err)) {
goto out
}
...
out:
error_propagate(errp, err);
even though other paths to label out still need the error_propagate().
For an actual example, see sclp_realize().
Without the "when strict", Coccinelle transforms vfio_msix_setup(),
incorrectly. I don't know what exactly "when strict" does, only that
it helps here.
The match of return is narrower than what I want, but I can't figure
out how to express "return where the operand doesn't use @err". For
an example where it's too narrow, see vfio_intx_enable().
Silently fails to convert hw/arm/armsse.c, because Coccinelle gets
confused by ARMSSE being used both as typedef and function-like macro
there. Converted manually.
Line breaks tidied up manually. One nested declaration of @local_err
deleted manually. Preexisting unwanted blank line dropped in
hw/riscv/sifive_e.c.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-35-armbru@redhat.com>
2020-07-07 18:06:02 +02:00
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type2_opts, errp)) {
|
2018-10-17 10:26:35 +02:00
|
|
|
return;
|
|
|
|
}
|
2014-04-23 15:42:42 +02:00
|
|
|
save_opt(&type2.manufacturer, opts, "manufacturer");
|
|
|
|
save_opt(&type2.product, opts, "product");
|
|
|
|
save_opt(&type2.version, opts, "version");
|
|
|
|
save_opt(&type2.serial, opts, "serial");
|
|
|
|
save_opt(&type2.asset, opts, "asset");
|
|
|
|
save_opt(&type2.location, opts, "location");
|
|
|
|
return;
|
|
|
|
case 3:
|
error: Eliminate error_propagate() with Coccinelle, part 1
When all we do with an Error we receive into a local variable is
propagating to somewhere else, we can just as well receive it there
right away. Convert
if (!foo(..., &err)) {
...
error_propagate(errp, err);
...
return ...
}
to
if (!foo(..., errp)) {
...
...
return ...
}
where nothing else needs @err. Coccinelle script:
@rule1 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
binary operator op;
constant c1, c2;
symbol false;
@@
if (
(
- fun(args, &err, args2)
+ fun(args, errp, args2)
|
- !fun(args, &err, args2)
+ !fun(args, errp, args2)
|
- fun(args, &err, args2) op c1
+ fun(args, errp, args2) op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
)
}
@rule2 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
expression var;
binary operator op;
constant c1, c2;
symbol false;
@@
- var = fun(args, &err, args2);
+ var = fun(args, errp, args2);
... when != err
if (
(
var
|
!var
|
var op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
|
return var;
)
}
@depends on rule1 || rule2@
identifier err;
@@
- Error *err = NULL;
... when != err
Not exactly elegant, I'm afraid.
The "when != lbl:" is necessary to avoid transforming
if (fun(args, &err)) {
goto out
}
...
out:
error_propagate(errp, err);
even though other paths to label out still need the error_propagate().
For an actual example, see sclp_realize().
Without the "when strict", Coccinelle transforms vfio_msix_setup(),
incorrectly. I don't know what exactly "when strict" does, only that
it helps here.
The match of return is narrower than what I want, but I can't figure
out how to express "return where the operand doesn't use @err". For
an example where it's too narrow, see vfio_intx_enable().
Silently fails to convert hw/arm/armsse.c, because Coccinelle gets
confused by ARMSSE being used both as typedef and function-like macro
there. Converted manually.
Line breaks tidied up manually. One nested declaration of @local_err
deleted manually. Preexisting unwanted blank line dropped in
hw/riscv/sifive_e.c.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-35-armbru@redhat.com>
2020-07-07 18:06:02 +02:00
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type3_opts, errp)) {
|
2018-10-17 10:26:35 +02:00
|
|
|
return;
|
|
|
|
}
|
2014-04-23 15:42:42 +02:00
|
|
|
save_opt(&type3.manufacturer, opts, "manufacturer");
|
|
|
|
save_opt(&type3.version, opts, "version");
|
|
|
|
save_opt(&type3.serial, opts, "serial");
|
|
|
|
save_opt(&type3.asset, opts, "asset");
|
|
|
|
save_opt(&type3.sku, opts, "sku");
|
|
|
|
return;
|
|
|
|
case 4:
|
error: Eliminate error_propagate() with Coccinelle, part 1
When all we do with an Error we receive into a local variable is
propagating to somewhere else, we can just as well receive it there
right away. Convert
if (!foo(..., &err)) {
...
error_propagate(errp, err);
...
return ...
}
to
if (!foo(..., errp)) {
...
...
return ...
}
where nothing else needs @err. Coccinelle script:
@rule1 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
binary operator op;
constant c1, c2;
symbol false;
@@
if (
(
- fun(args, &err, args2)
+ fun(args, errp, args2)
|
- !fun(args, &err, args2)
+ !fun(args, errp, args2)
|
- fun(args, &err, args2) op c1
+ fun(args, errp, args2) op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
)
}
@rule2 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
expression var;
binary operator op;
constant c1, c2;
symbol false;
@@
- var = fun(args, &err, args2);
+ var = fun(args, errp, args2);
... when != err
if (
(
var
|
!var
|
var op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
|
return var;
)
}
@depends on rule1 || rule2@
identifier err;
@@
- Error *err = NULL;
... when != err
Not exactly elegant, I'm afraid.
The "when != lbl:" is necessary to avoid transforming
if (fun(args, &err)) {
goto out
}
...
out:
error_propagate(errp, err);
even though other paths to label out still need the error_propagate().
For an actual example, see sclp_realize().
Without the "when strict", Coccinelle transforms vfio_msix_setup(),
incorrectly. I don't know what exactly "when strict" does, only that
it helps here.
The match of return is narrower than what I want, but I can't figure
out how to express "return where the operand doesn't use @err". For
an example where it's too narrow, see vfio_intx_enable().
Silently fails to convert hw/arm/armsse.c, because Coccinelle gets
confused by ARMSSE being used both as typedef and function-like macro
there. Converted manually.
Line breaks tidied up manually. One nested declaration of @local_err
deleted manually. Preexisting unwanted blank line dropped in
hw/riscv/sifive_e.c.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-35-armbru@redhat.com>
2020-07-07 18:06:02 +02:00
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type4_opts, errp)) {
|
2018-10-17 10:26:35 +02:00
|
|
|
return;
|
|
|
|
}
|
2014-04-23 15:42:42 +02:00
|
|
|
save_opt(&type4.sock_pfx, opts, "sock_pfx");
|
2024-01-23 19:42:26 +01:00
|
|
|
type4.processor_family = qemu_opt_get_number(opts,
|
|
|
|
"processor-family",
|
|
|
|
0x01 /* Other */);
|
2014-04-23 15:42:42 +02:00
|
|
|
save_opt(&type4.manufacturer, opts, "manufacturer");
|
|
|
|
save_opt(&type4.version, opts, "version");
|
|
|
|
save_opt(&type4.serial, opts, "serial");
|
|
|
|
save_opt(&type4.asset, opts, "asset");
|
|
|
|
save_opt(&type4.part, opts, "part");
|
2022-01-25 17:31:18 +01:00
|
|
|
/* If the value is 0, it will take the value from the CPU model. */
|
|
|
|
type4.processor_id = qemu_opt_get_number(opts, "processor-id", 0);
|
2020-08-06 05:56:33 +02:00
|
|
|
type4.max_speed = qemu_opt_get_number(opts, "max-speed",
|
|
|
|
DEFAULT_CPU_SPEED);
|
|
|
|
type4.current_speed = qemu_opt_get_number(opts, "current-speed",
|
|
|
|
DEFAULT_CPU_SPEED);
|
|
|
|
if (type4.max_speed > UINT16_MAX ||
|
|
|
|
type4.current_speed > UINT16_MAX) {
|
|
|
|
error_setg(errp, "SMBIOS CPU speed is too large (> %d)",
|
|
|
|
UINT16_MAX);
|
|
|
|
}
|
2014-04-23 15:42:42 +02:00
|
|
|
return;
|
hw/smbios: support for type 8 (port connector)
PATCH v1: add support for SMBIOS type 8 to qemu
PATCH v2: incorporate patch v1 feedback and add smbios type=8 to qemu-options
internal_reference: internal reference designator
external_reference: external reference designator
connector_type: hex value for port connector type (see SMBIOS 7.9.2)
port_type: hex value for port type (see SMBIOS 7.9.3)
After studying various vendor implementationsi (Dell, Lenovo, MSI),
the value of internal connector type was hard-coded to 0x0 (None).
Example usage:
-smbios type=8,internal_reference=JUSB1,external_reference=USB1,connector_type=0x12,port_type=0x10 \
-smbios type=8,internal_reference=JAUD1,external_reference="Audio Jack",connector_type=0x1f,port_type=0x1d \
-smbios type=8,internal_reference=LAN,external_reference=Ethernet,connector_type=0x0b,port_type=0x1f \
-smbios type=8,internal_reference=PS2,external_reference=Mouse,connector_type=0x0f,port_type=0x0e \
-smbios type=8,internal_reference=PS2,external_reference=Keyboard,connector_type=0x0f,port_type=0x0d
Signed-off-by: Hal Martin <hal.martin@gmail.com>
Message-Id: <20220812135153.17859-1-hal.martin@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-08-12 15:51:53 +02:00
|
|
|
case 8:
|
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type8_opts, errp)) {
|
|
|
|
return;
|
|
|
|
}
|
2023-09-22 14:42:02 +02:00
|
|
|
struct type8_instance *t8_i;
|
|
|
|
t8_i = g_new0(struct type8_instance, 1);
|
|
|
|
save_opt(&t8_i->internal_reference, opts, "internal_reference");
|
|
|
|
save_opt(&t8_i->external_reference, opts, "external_reference");
|
|
|
|
t8_i->connector_type = qemu_opt_get_number(opts,
|
|
|
|
"connector_type", 0);
|
|
|
|
t8_i->port_type = qemu_opt_get_number(opts, "port_type", 0);
|
|
|
|
QTAILQ_INSERT_TAIL(&type8, t8_i, next);
|
hw/smbios: support for type 8 (port connector)
PATCH v1: add support for SMBIOS type 8 to qemu
PATCH v2: incorporate patch v1 feedback and add smbios type=8 to qemu-options
internal_reference: internal reference designator
external_reference: external reference designator
connector_type: hex value for port connector type (see SMBIOS 7.9.2)
port_type: hex value for port type (see SMBIOS 7.9.3)
After studying various vendor implementationsi (Dell, Lenovo, MSI),
the value of internal connector type was hard-coded to 0x0 (None).
Example usage:
-smbios type=8,internal_reference=JUSB1,external_reference=USB1,connector_type=0x12,port_type=0x10 \
-smbios type=8,internal_reference=JAUD1,external_reference="Audio Jack",connector_type=0x1f,port_type=0x1d \
-smbios type=8,internal_reference=LAN,external_reference=Ethernet,connector_type=0x0b,port_type=0x1f \
-smbios type=8,internal_reference=PS2,external_reference=Mouse,connector_type=0x0f,port_type=0x0e \
-smbios type=8,internal_reference=PS2,external_reference=Keyboard,connector_type=0x0f,port_type=0x0d
Signed-off-by: Hal Martin <hal.martin@gmail.com>
Message-Id: <20220812135153.17859-1-hal.martin@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-08-12 15:51:53 +02:00
|
|
|
return;
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
case 11:
|
error: Eliminate error_propagate() with Coccinelle, part 1
When all we do with an Error we receive into a local variable is
propagating to somewhere else, we can just as well receive it there
right away. Convert
if (!foo(..., &err)) {
...
error_propagate(errp, err);
...
return ...
}
to
if (!foo(..., errp)) {
...
...
return ...
}
where nothing else needs @err. Coccinelle script:
@rule1 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
binary operator op;
constant c1, c2;
symbol false;
@@
if (
(
- fun(args, &err, args2)
+ fun(args, errp, args2)
|
- !fun(args, &err, args2)
+ !fun(args, errp, args2)
|
- fun(args, &err, args2) op c1
+ fun(args, errp, args2) op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
)
}
@rule2 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
expression var;
binary operator op;
constant c1, c2;
symbol false;
@@
- var = fun(args, &err, args2);
+ var = fun(args, errp, args2);
... when != err
if (
(
var
|
!var
|
var op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
|
return var;
)
}
@depends on rule1 || rule2@
identifier err;
@@
- Error *err = NULL;
... when != err
Not exactly elegant, I'm afraid.
The "when != lbl:" is necessary to avoid transforming
if (fun(args, &err)) {
goto out
}
...
out:
error_propagate(errp, err);
even though other paths to label out still need the error_propagate().
For an actual example, see sclp_realize().
Without the "when strict", Coccinelle transforms vfio_msix_setup(),
incorrectly. I don't know what exactly "when strict" does, only that
it helps here.
The match of return is narrower than what I want, but I can't figure
out how to express "return where the operand doesn't use @err". For
an example where it's too narrow, see vfio_intx_enable().
Silently fails to convert hw/arm/armsse.c, because Coccinelle gets
confused by ARMSSE being used both as typedef and function-like macro
there. Converted manually.
Line breaks tidied up manually. One nested declaration of @local_err
deleted manually. Preexisting unwanted blank line dropped in
hw/riscv/sifive_e.c.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-35-armbru@redhat.com>
2020-07-07 18:06:02 +02:00
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type11_opts, errp)) {
|
2018-10-17 10:26:35 +02:00
|
|
|
return;
|
|
|
|
}
|
2020-09-23 15:38:02 +02:00
|
|
|
if (!save_opt_list(&type11.nvalues, &type11.values, opts, errp)) {
|
|
|
|
return;
|
|
|
|
}
|
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-28 22:51:36 +02:00
|
|
|
return;
|
2014-04-23 15:42:42 +02:00
|
|
|
case 17:
|
error: Eliminate error_propagate() with Coccinelle, part 1
When all we do with an Error we receive into a local variable is
propagating to somewhere else, we can just as well receive it there
right away. Convert
if (!foo(..., &err)) {
...
error_propagate(errp, err);
...
return ...
}
to
if (!foo(..., errp)) {
...
...
return ...
}
where nothing else needs @err. Coccinelle script:
@rule1 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
binary operator op;
constant c1, c2;
symbol false;
@@
if (
(
- fun(args, &err, args2)
+ fun(args, errp, args2)
|
- !fun(args, &err, args2)
+ !fun(args, errp, args2)
|
- fun(args, &err, args2) op c1
+ fun(args, errp, args2) op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
)
}
@rule2 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
expression var;
binary operator op;
constant c1, c2;
symbol false;
@@
- var = fun(args, &err, args2);
+ var = fun(args, errp, args2);
... when != err
if (
(
var
|
!var
|
var op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
|
return var;
)
}
@depends on rule1 || rule2@
identifier err;
@@
- Error *err = NULL;
... when != err
Not exactly elegant, I'm afraid.
The "when != lbl:" is necessary to avoid transforming
if (fun(args, &err)) {
goto out
}
...
out:
error_propagate(errp, err);
even though other paths to label out still need the error_propagate().
For an actual example, see sclp_realize().
Without the "when strict", Coccinelle transforms vfio_msix_setup(),
incorrectly. I don't know what exactly "when strict" does, only that
it helps here.
The match of return is narrower than what I want, but I can't figure
out how to express "return where the operand doesn't use @err". For
an example where it's too narrow, see vfio_intx_enable().
Silently fails to convert hw/arm/armsse.c, because Coccinelle gets
confused by ARMSSE being used both as typedef and function-like macro
there. Converted manually.
Line breaks tidied up manually. One nested declaration of @local_err
deleted manually. Preexisting unwanted blank line dropped in
hw/riscv/sifive_e.c.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-35-armbru@redhat.com>
2020-07-07 18:06:02 +02:00
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type17_opts, errp)) {
|
2018-10-17 10:26:35 +02:00
|
|
|
return;
|
|
|
|
}
|
2014-04-23 15:42:42 +02:00
|
|
|
save_opt(&type17.loc_pfx, opts, "loc_pfx");
|
|
|
|
save_opt(&type17.bank, opts, "bank");
|
|
|
|
save_opt(&type17.manufacturer, opts, "manufacturer");
|
|
|
|
save_opt(&type17.serial, opts, "serial");
|
|
|
|
save_opt(&type17.asset, opts, "asset");
|
|
|
|
save_opt(&type17.part, opts, "part");
|
2015-03-11 18:58:01 +01:00
|
|
|
type17.speed = qemu_opt_get_number(opts, "speed", 0);
|
2014-04-23 15:42:42 +02:00
|
|
|
return;
|
hw/smbios: support for type 41 (onboard devices extended information)
Type 41 defines the attributes of devices that are onboard. The
original intent was to imply the BIOS had some level of control over
the enablement of the associated devices.
If network devices are present in this table, by default, udev will
name the corresponding interfaces enoX, X being the instance number.
Without such information, udev will fallback to using the PCI ID and
this usually gives ens3 or ens4. This can be a bit annoying as the
name of the network card may depend on the order of options and may
change if a new PCI device is added earlier on the commande line.
Being able to provide SMBIOS type 41 entry ensure the name of the
interface won't change and helps the user guess the right name without
booting a first time.
This can be invoked with:
$QEMU -netdev user,id=internet
-device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet,id=internet-dev \
-smbios type=41,designation='Onboard LAN',instance=1,kind=ethernet,pcidev=internet-dev
The PCI segment is assumed to be 0. This should hold true for most
cases.
$ dmidecode -t 41
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard LAN
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:09.0
$ ip -brief a
lo UNKNOWN 127.0.0.1/8 ::1/128
eno1 UP 10.0.2.14/24 fec0::5254:ff:fe00:42/64 fe80::5254:ff:fe00:42/64
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
Message-Id: <20210401171138.62970-1-vincent@bernat.ch>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-04-01 19:11:38 +02:00
|
|
|
case 41: {
|
2023-09-22 14:42:02 +02:00
|
|
|
struct type41_instance *t41_i;
|
hw/smbios: support for type 41 (onboard devices extended information)
Type 41 defines the attributes of devices that are onboard. The
original intent was to imply the BIOS had some level of control over
the enablement of the associated devices.
If network devices are present in this table, by default, udev will
name the corresponding interfaces enoX, X being the instance number.
Without such information, udev will fallback to using the PCI ID and
this usually gives ens3 or ens4. This can be a bit annoying as the
name of the network card may depend on the order of options and may
change if a new PCI device is added earlier on the commande line.
Being able to provide SMBIOS type 41 entry ensure the name of the
interface won't change and helps the user guess the right name without
booting a first time.
This can be invoked with:
$QEMU -netdev user,id=internet
-device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet,id=internet-dev \
-smbios type=41,designation='Onboard LAN',instance=1,kind=ethernet,pcidev=internet-dev
The PCI segment is assumed to be 0. This should hold true for most
cases.
$ dmidecode -t 41
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard LAN
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:09.0
$ ip -brief a
lo UNKNOWN 127.0.0.1/8 ::1/128
eno1 UP 10.0.2.14/24 fec0::5254:ff:fe00:42/64 fe80::5254:ff:fe00:42/64
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
Message-Id: <20210401171138.62970-1-vincent@bernat.ch>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-04-01 19:11:38 +02:00
|
|
|
Error *local_err = NULL;
|
|
|
|
|
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type41_opts, errp)) {
|
|
|
|
return;
|
|
|
|
}
|
2023-09-22 14:42:02 +02:00
|
|
|
t41_i = g_new0(struct type41_instance, 1);
|
|
|
|
save_opt(&t41_i->designation, opts, "designation");
|
|
|
|
t41_i->kind = qapi_enum_parse(&type41_kind_lookup,
|
|
|
|
qemu_opt_get(opts, "kind"),
|
|
|
|
0, &local_err) + 1;
|
|
|
|
t41_i->kind |= 0x80; /* enabled */
|
hw/smbios: support for type 41 (onboard devices extended information)
Type 41 defines the attributes of devices that are onboard. The
original intent was to imply the BIOS had some level of control over
the enablement of the associated devices.
If network devices are present in this table, by default, udev will
name the corresponding interfaces enoX, X being the instance number.
Without such information, udev will fallback to using the PCI ID and
this usually gives ens3 or ens4. This can be a bit annoying as the
name of the network card may depend on the order of options and may
change if a new PCI device is added earlier on the commande line.
Being able to provide SMBIOS type 41 entry ensure the name of the
interface won't change and helps the user guess the right name without
booting a first time.
This can be invoked with:
$QEMU -netdev user,id=internet
-device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet,id=internet-dev \
-smbios type=41,designation='Onboard LAN',instance=1,kind=ethernet,pcidev=internet-dev
The PCI segment is assumed to be 0. This should hold true for most
cases.
$ dmidecode -t 41
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard LAN
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:09.0
$ ip -brief a
lo UNKNOWN 127.0.0.1/8 ::1/128
eno1 UP 10.0.2.14/24 fec0::5254:ff:fe00:42/64 fe80::5254:ff:fe00:42/64
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
Message-Id: <20210401171138.62970-1-vincent@bernat.ch>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-04-01 19:11:38 +02:00
|
|
|
if (local_err != NULL) {
|
|
|
|
error_propagate(errp, local_err);
|
2023-09-22 14:42:02 +02:00
|
|
|
g_free(t41_i);
|
hw/smbios: support for type 41 (onboard devices extended information)
Type 41 defines the attributes of devices that are onboard. The
original intent was to imply the BIOS had some level of control over
the enablement of the associated devices.
If network devices are present in this table, by default, udev will
name the corresponding interfaces enoX, X being the instance number.
Without such information, udev will fallback to using the PCI ID and
this usually gives ens3 or ens4. This can be a bit annoying as the
name of the network card may depend on the order of options and may
change if a new PCI device is added earlier on the commande line.
Being able to provide SMBIOS type 41 entry ensure the name of the
interface won't change and helps the user guess the right name without
booting a first time.
This can be invoked with:
$QEMU -netdev user,id=internet
-device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet,id=internet-dev \
-smbios type=41,designation='Onboard LAN',instance=1,kind=ethernet,pcidev=internet-dev
The PCI segment is assumed to be 0. This should hold true for most
cases.
$ dmidecode -t 41
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard LAN
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:09.0
$ ip -brief a
lo UNKNOWN 127.0.0.1/8 ::1/128
eno1 UP 10.0.2.14/24 fec0::5254:ff:fe00:42/64 fe80::5254:ff:fe00:42/64
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
Message-Id: <20210401171138.62970-1-vincent@bernat.ch>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-04-01 19:11:38 +02:00
|
|
|
return;
|
|
|
|
}
|
2023-09-22 14:42:02 +02:00
|
|
|
t41_i->instance = qemu_opt_get_number(opts, "instance", 1);
|
|
|
|
save_opt(&t41_i->pcidev, opts, "pcidev");
|
hw/smbios: support for type 41 (onboard devices extended information)
Type 41 defines the attributes of devices that are onboard. The
original intent was to imply the BIOS had some level of control over
the enablement of the associated devices.
If network devices are present in this table, by default, udev will
name the corresponding interfaces enoX, X being the instance number.
Without such information, udev will fallback to using the PCI ID and
this usually gives ens3 or ens4. This can be a bit annoying as the
name of the network card may depend on the order of options and may
change if a new PCI device is added earlier on the commande line.
Being able to provide SMBIOS type 41 entry ensure the name of the
interface won't change and helps the user guess the right name without
booting a first time.
This can be invoked with:
$QEMU -netdev user,id=internet
-device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet,id=internet-dev \
-smbios type=41,designation='Onboard LAN',instance=1,kind=ethernet,pcidev=internet-dev
The PCI segment is assumed to be 0. This should hold true for most
cases.
$ dmidecode -t 41
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard LAN
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:09.0
$ ip -brief a
lo UNKNOWN 127.0.0.1/8 ::1/128
eno1 UP 10.0.2.14/24 fec0::5254:ff:fe00:42/64 fe80::5254:ff:fe00:42/64
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
Message-Id: <20210401171138.62970-1-vincent@bernat.ch>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-04-01 19:11:38 +02:00
|
|
|
|
2023-09-22 14:42:02 +02:00
|
|
|
QTAILQ_INSERT_TAIL(&type41, t41_i, next);
|
hw/smbios: support for type 41 (onboard devices extended information)
Type 41 defines the attributes of devices that are onboard. The
original intent was to imply the BIOS had some level of control over
the enablement of the associated devices.
If network devices are present in this table, by default, udev will
name the corresponding interfaces enoX, X being the instance number.
Without such information, udev will fallback to using the PCI ID and
this usually gives ens3 or ens4. This can be a bit annoying as the
name of the network card may depend on the order of options and may
change if a new PCI device is added earlier on the commande line.
Being able to provide SMBIOS type 41 entry ensure the name of the
interface won't change and helps the user guess the right name without
booting a first time.
This can be invoked with:
$QEMU -netdev user,id=internet
-device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet,id=internet-dev \
-smbios type=41,designation='Onboard LAN',instance=1,kind=ethernet,pcidev=internet-dev
The PCI segment is assumed to be 0. This should hold true for most
cases.
$ dmidecode -t 41
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard LAN
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:09.0
$ ip -brief a
lo UNKNOWN 127.0.0.1/8 ::1/128
eno1 UP 10.0.2.14/24 fec0::5254:ff:fe00:42/64 fe80::5254:ff:fe00:42/64
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
Message-Id: <20210401171138.62970-1-vincent@bernat.ch>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-04-01 19:11:38 +02:00
|
|
|
return;
|
|
|
|
}
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
default:
|
2018-10-17 10:26:35 +02:00
|
|
|
error_setg(errp,
|
|
|
|
"Don't know how to build fields for SMBIOS type %ld",
|
|
|
|
type);
|
|
|
|
return;
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-10-17 10:26:35 +02:00
|
|
|
error_setg(errp, "Must specify type= or file=");
|
qemu: Add support for SMBIOS command line otions (Alex Williamson)
Create a new -smbios option (x86-only) to allow binary SMBIOS entries
to be passed through to the BIOS or modify the default values of
individual fields of type 0 and 1 entries on the command line.
Binary SMBIOS entries can be generated as follows:
dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
These can then be passed to the BIOS using this switch:
-smbios file=smbios_type_1.bin
Command line generation supports the following syntax:
-smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
-smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
[,uuid=$(uuidgen)][,sku=str][,family=str]
For instance, to add a serial number to the type 1 table:
-smbios type=1,serial=0123456789
Interface is extensible to support more fields/tables as needed.
aliguori: remove texi formatting from help output
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7163 c046a42c-6fe2-441c-8c8c-71466251a162
2009-04-17 20:59:56 +02:00
|
|
|
}
|