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 22:59:56 +04:00
|
|
|
/*
|
|
|
|
* SMBIOS Support
|
|
|
|
*
|
|
|
|
* Copyright (C) 2009 Hewlett-Packard Development Company, L.P.
|
2013-08-16 17:18:29 +04: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 22:59:56 +04:00
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Alex Williamson <alex.williamson@hp.com>
|
2013-08-16 17:18:29 +04: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 22:59:56 +04: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 20:44:23 +04: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 22:59:56 +04:00
|
|
|
*/
|
|
|
|
|
2016-01-26 21:17:30 +03:00
|
|
|
#include "qemu/osdep.h"
|
2018-06-25 15:42:02 +03: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 11:01:28 +03:00
|
|
|
#include "qapi/error.h"
|
2013-08-16 17:18:29 +04:00
|
|
|
#include "qemu/config-file.h"
|
2019-05-23 17:35:07 +03:00
|
|
|
#include "qemu/module.h"
|
2018-02-01 14:18:46 +03:00
|
|
|
#include "qemu/option.h"
|
2012-12-17 21:20:04 +04:00
|
|
|
#include "sysemu/sysemu.h"
|
2016-09-21 07:27:14 +03:00
|
|
|
#include "qemu/uuid.h"
|
2018-12-11 19:34:06 +03:00
|
|
|
#include "hw/firmware/smbios.h"
|
2013-02-04 18:40:22 +04:00
|
|
|
#include "hw/loader.h"
|
2019-05-18 23:54:20 +03: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 20:11:38 +03:00
|
|
|
#include "hw/pci/pci_bus.h"
|
2022-12-22 13:03:28 +03:00
|
|
|
#include "hw/pci/pci_device.h"
|
2016-06-10 12:15:40 +03:00
|
|
|
#include "smbios_build.h"
|
2014-04-23 17:42:38 +04:00
|
|
|
|
2024-03-14 18:22:48 +03:00
|
|
|
/*
|
|
|
|
* SMBIOS tables provided by user with '-smbios file=<foo>' option
|
|
|
|
*/
|
|
|
|
uint8_t *usr_blobs;
|
|
|
|
size_t usr_blobs_len;
|
|
|
|
static unsigned usr_table_max;
|
|
|
|
static unsigned usr_table_cnt;
|
2014-04-23 17:42:38 +04:00
|
|
|
|
2016-06-10 12:15:40 +03:00
|
|
|
uint8_t *smbios_tables;
|
|
|
|
size_t smbios_tables_len;
|
|
|
|
unsigned smbios_table_max;
|
|
|
|
unsigned smbios_table_cnt;
|
2015-09-07 12:39:28 +03:00
|
|
|
|
|
|
|
static SmbiosEntryPoint ep;
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2009-07-31 21:49:14 +04:00
|
|
|
static int smbios_type4_count = 0;
|
2014-04-23 17:42:42 +04:00
|
|
|
static bool smbios_have_defaults;
|
2024-03-14 18:22:46 +03:00
|
|
|
static uint32_t smbios_cpuid_version, smbios_cpuid_features;
|
2009-07-31 21:49:14 +04:00
|
|
|
|
2024-03-14 18:22:51 +03:00
|
|
|
DECLARE_BITMAP(smbios_have_binfile_bitmap, SMBIOS_MAX_TYPE + 1);
|
|
|
|
DECLARE_BITMAP(smbios_have_fields_bitmap, SMBIOS_MAX_TYPE + 1);
|
2013-08-16 17:18:30 +04:00
|
|
|
|
2024-03-14 18:22:51 +03:00
|
|
|
smbios_type0_t smbios_type0;
|
|
|
|
smbios_type1_t smbios_type1;
|
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 17:18:31 +04:00
|
|
|
|
2014-04-23 17:42:42 +04: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 06:56:33 +03: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 17:42:42 +04:00
|
|
|
static struct {
|
2024-01-23 21:42:26 +03:00
|
|
|
uint16_t processor_family;
|
2014-04-23 17:42:42 +04:00
|
|
|
const char *sock_pfx, *manufacturer, *version, *serial, *asset, *part;
|
2020-08-06 06:56:33 +03:00
|
|
|
uint64_t max_speed;
|
|
|
|
uint64_t current_speed;
|
2022-01-25 19:31:18 +03:00
|
|
|
uint64_t processor_id;
|
2020-08-06 06:56:33 +03:00
|
|
|
} type4 = {
|
|
|
|
.max_speed = DEFAULT_CPU_SPEED,
|
2022-01-25 19:31:18 +03:00
|
|
|
.current_speed = DEFAULT_CPU_SPEED,
|
|
|
|
.processor_id = 0,
|
2024-01-23 21:42:26 +03:00
|
|
|
.processor_family = 0x01, /* Other */
|
2020-08-06 06:56:33 +03:00
|
|
|
};
|
2014-04-23 17:42:42 +04: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 16:51:53 +03: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);
|
|
|
|
|
2024-02-21 20:00:26 +03:00
|
|
|
/* type 9 instance for parsing */
|
|
|
|
struct type9_instance {
|
2024-02-21 20:00:27 +03:00
|
|
|
const char *slot_designation, *pcidev;
|
2024-02-21 20:00:26 +03:00
|
|
|
uint8_t slot_type, slot_data_bus_width, current_usage, slot_length,
|
|
|
|
slot_characteristics1, slot_characteristics2;
|
|
|
|
uint16_t slot_id;
|
|
|
|
QTAILQ_ENTRY(type9_instance) next;
|
|
|
|
};
|
|
|
|
static QTAILQ_HEAD(, type9_instance) type9 = QTAILQ_HEAD_INITIALIZER(type9);
|
|
|
|
|
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 23:51:36 +03:00
|
|
|
static struct {
|
|
|
|
size_t nvalues;
|
2020-09-23 16:38:02 +03: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 23:51:36 +03:00
|
|
|
} type11;
|
|
|
|
|
2014-04-23 17:42:42 +04:00
|
|
|
static struct {
|
|
|
|
const char *loc_pfx, *bank, *manufacturer, *serial, *asset, *part;
|
2015-03-11 20:58:01 +03:00
|
|
|
uint16_t speed;
|
2014-04-23 17:42:42 +04: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 20:11:38 +03: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 17:18:29 +04: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 18:09:54 +04:00
|
|
|
},{
|
|
|
|
.name = "uefi",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
|
|
|
.help = "uefi support",
|
2013-08-16 17:18:29 +04: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 17:42:42 +04: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 06:56:33 +03: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 17:42:42 +04: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 21:42:26 +03:00
|
|
|
}, {
|
|
|
|
.name = "processor-family",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "processor family",
|
2022-01-25 19:31:18 +03:00
|
|
|
}, {
|
|
|
|
.name = "processor-id",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "processor id",
|
2014-04-23 17:42:42 +04: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 16:51:53 +03:00
|
|
|
static const QemuOptDesc qemu_smbios_type8_opts[] = {
|
2024-01-29 11:03:08 +03: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 16:51:53 +03: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 11:03:08 +03: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 16:51:53 +03:00
|
|
|
};
|
|
|
|
|
2024-02-21 20:00:26 +03:00
|
|
|
static const QemuOptDesc qemu_smbios_type9_opts[] = {
|
|
|
|
{
|
|
|
|
.name = "type",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "SMBIOS element type",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "slot_designation",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "string number for reference designation",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "slot_type",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "connector type",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "slot_data_bus_width",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "port type",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "current_usage",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "current usage",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "slot_length",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "system slot length",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "slot_id",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "system slot id",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "slot_characteristics1",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "slot characteristics1, see the spec",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "slot_characteristics2",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "slot characteristics2, see the spec",
|
|
|
|
},
|
2024-02-21 20:00:27 +03:00
|
|
|
{
|
|
|
|
.name = "pci_device",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "PCI device, if provided."
|
|
|
|
}
|
2024-02-21 20:00:26 +03: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 23:51:36 +03:00
|
|
|
static const QemuOptDesc qemu_smbios_type11_opts[] = {
|
2024-01-29 11:03:07 +03: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 23:51:36 +03:00
|
|
|
{
|
|
|
|
.name = "value",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "OEM string data",
|
|
|
|
},
|
2020-09-23 16:38:02 +03:00
|
|
|
{
|
|
|
|
.name = "path",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "OEM string data from file",
|
|
|
|
},
|
2024-01-29 11:03:07 +03: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 23:51:36 +03:00
|
|
|
};
|
|
|
|
|
2014-04-23 17:42:42 +04: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 20:58:01 +03:00
|
|
|
},{
|
|
|
|
.name = "speed",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
.help = "maximum capable speed",
|
2014-04-23 17:42:42 +04: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 20:11:38 +03: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 17:18:29 +04:00
|
|
|
static void smbios_register_config(void)
|
|
|
|
{
|
|
|
|
qemu_add_opts(&qemu_smbios_opts);
|
|
|
|
}
|
|
|
|
|
2016-02-16 23:59:07 +03:00
|
|
|
opts_init(smbios_register_config);
|
2013-08-16 17:18:29 +04:00
|
|
|
|
2020-09-23 16:38:03 +03: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
|
|
|
|
|
2024-03-14 18:22:53 +03:00
|
|
|
static bool smbios_check_type4_count(uint32_t expected_t4_count, Error **errp)
|
2009-07-31 21:49:14 +04:00
|
|
|
{
|
2024-03-14 18:22:46 +03:00
|
|
|
if (smbios_type4_count && smbios_type4_count != expected_t4_count) {
|
2024-03-14 18:22:53 +03:00
|
|
|
error_setg(errp, "Expected %d SMBIOS Type 4 tables, got %d instead",
|
|
|
|
expected_t4_count, smbios_type4_count);
|
|
|
|
return false;
|
2009-07-31 21:49:14 +04:00
|
|
|
}
|
2024-03-14 18:22:53 +03:00
|
|
|
return true;
|
2024-03-14 18:22:49 +03:00
|
|
|
}
|
2020-09-23 16:38:03 +03:00
|
|
|
|
2024-03-14 18:22:54 +03:00
|
|
|
bool smbios_validate_table(SmbiosEntryPointType ep_type, Error **errp)
|
2024-03-14 18:22:49 +03:00
|
|
|
{
|
2024-03-14 18:22:54 +03:00
|
|
|
if (ep_type == SMBIOS_ENTRY_POINT_TYPE_32 &&
|
2020-09-23 16:38:03 +03:00
|
|
|
smbios_tables_len > SMBIOS_21_MAX_TABLES_LEN) {
|
2024-03-14 18:22:53 +03:00
|
|
|
error_setg(errp, "SMBIOS 2.1 table length %zu exceeds %d",
|
|
|
|
smbios_tables_len, SMBIOS_21_MAX_TABLES_LEN);
|
|
|
|
return false;
|
2020-09-23 16:38:03 +03:00
|
|
|
}
|
2024-03-14 18:22:53 +03:00
|
|
|
return true;
|
2009-07-31 21:49:14 +04: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 22:59:56 +04:00
|
|
|
|
2016-06-10 12:15:40 +03:00
|
|
|
bool smbios_skip_table(uint8_t type, bool required_table)
|
2014-04-23 17:42:42 +04:00
|
|
|
{
|
2024-03-14 18:22:51 +03:00
|
|
|
if (test_bit(type, smbios_have_binfile_bitmap)) {
|
2014-04-23 17:42:42 +04:00
|
|
|
return true; /* user provided their own binary blob(s) */
|
|
|
|
}
|
2024-03-14 18:22:51 +03:00
|
|
|
if (test_bit(type, smbios_have_fields_bitmap)) {
|
2014-04-23 17:42:42 +04:00
|
|
|
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 17:33:20 +03:00
|
|
|
#define T0_BASE 0x000
|
|
|
|
#define T1_BASE 0x100
|
|
|
|
#define T2_BASE 0x200
|
|
|
|
#define T3_BASE 0x300
|
|
|
|
#define T4_BASE 0x400
|
2024-02-21 20:00:26 +03:00
|
|
|
#define T9_BASE 0x900
|
2022-02-23 17:33:20 +03:00
|
|
|
#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 17:42:42 +04:00
|
|
|
static void smbios_build_type_0_table(void)
|
|
|
|
{
|
2022-02-23 17:33:20 +03:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(0, T0_BASE, false); /* optional, leave up to BIOS */
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2024-03-14 18:22:51 +03:00
|
|
|
SMBIOS_TABLE_SET_STR(0, vendor_str, smbios_type0.vendor);
|
|
|
|
SMBIOS_TABLE_SET_STR(0, bios_version_str, smbios_type0.version);
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2014-05-19 18:09:53 +04:00
|
|
|
t->bios_starting_address_segment = cpu_to_le16(0xE800); /* from SeaBIOS */
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2024-03-14 18:22:51 +03:00
|
|
|
SMBIOS_TABLE_SET_STR(0, bios_release_date_str, smbios_type0.date);
|
2014-04-23 17:42:42 +04:00
|
|
|
|
|
|
|
t->bios_rom_size = 0; /* hardcoded in SeaBIOS with FIXME comment */
|
|
|
|
|
2014-05-19 18:09:54 +04:00
|
|
|
t->bios_characteristics = cpu_to_le64(0x08); /* Not supported */
|
2014-04-23 17:42:42 +04:00
|
|
|
t->bios_characteristics_extension_bytes[0] = 0;
|
2014-05-19 18:09:54 +04:00
|
|
|
t->bios_characteristics_extension_bytes[1] = 0x14; /* TCD/SVVP | VM */
|
2024-03-14 18:22:51 +03:00
|
|
|
if (smbios_type0.uefi) {
|
2014-05-19 18:09:54 +04:00
|
|
|
t->bios_characteristics_extension_bytes[1] |= 0x08; /* |= UEFI */
|
|
|
|
}
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2024-03-14 18:22:51 +03:00
|
|
|
if (smbios_type0.have_major_minor) {
|
|
|
|
t->system_bios_major_release = smbios_type0.major;
|
|
|
|
t->system_bios_minor_release = smbios_type0.minor;
|
2014-04-23 17:42:42 +04:00
|
|
|
} 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 16:26:08 +03:00
|
|
|
/* Encode UUID from the big endian encoding described on RFC4122 to the wire
|
|
|
|
* format specified by SMBIOS version 2.6.
|
|
|
|
*/
|
2016-09-21 07:27:22 +03: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 16:26:08 +03:00
|
|
|
{
|
2016-09-28 17:38:10 +03:00
|
|
|
memcpy(uuid, in, 16);
|
2024-03-27 12:09:11 +03:00
|
|
|
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);
|
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 16:26:08 +03:00
|
|
|
}
|
|
|
|
|
2014-04-23 17:42:42 +04:00
|
|
|
static void smbios_build_type_1_table(void)
|
|
|
|
{
|
2022-02-23 17:33:20 +03:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(1, T1_BASE, true); /* required */
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2024-03-14 18:22:51 +03:00
|
|
|
SMBIOS_TABLE_SET_STR(1, manufacturer_str, smbios_type1.manufacturer);
|
|
|
|
SMBIOS_TABLE_SET_STR(1, product_name_str, smbios_type1.product);
|
|
|
|
SMBIOS_TABLE_SET_STR(1, version_str, smbios_type1.version);
|
|
|
|
SMBIOS_TABLE_SET_STR(1, serial_number_str, smbios_type1.serial);
|
2014-04-23 17:42:42 +04:00
|
|
|
if (qemu_uuid_set) {
|
2016-09-21 07:27:22 +03:00
|
|
|
smbios_encode_uuid(&t->uuid, &qemu_uuid);
|
2014-04-23 17:42:42 +04: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 16:26:08 +03:00
|
|
|
memset(&t->uuid, 0, 16);
|
2014-04-23 17:42:42 +04:00
|
|
|
}
|
|
|
|
t->wake_up_type = 0x06; /* power switch */
|
2024-03-14 18:22:51 +03:00
|
|
|
SMBIOS_TABLE_SET_STR(1, sku_number_str, smbios_type1.sku);
|
|
|
|
SMBIOS_TABLE_SET_STR(1, family_str, smbios_type1.family);
|
2014-04-23 17:42:42 +04:00
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void smbios_build_type_2_table(void)
|
|
|
|
{
|
2022-02-23 17:33:20 +03:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(2, T2_BASE, false); /* optional */
|
2014-04-23 17:42:42 +04: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 18:09:53 +04:00
|
|
|
t->chassis_handle = cpu_to_le16(0x300); /* Type 3 (System enclosure) */
|
2014-04-23 17:42:42 +04: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 17:33:20 +03:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(3, T3_BASE, true); /* required */
|
2014-04-23 17:42:42 +04: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 18:09:53 +04:00
|
|
|
t->oem_defined = cpu_to_le32(0);
|
2014-04-23 17:42:42 +04:00
|
|
|
t->height = 0;
|
|
|
|
t->number_of_power_cords = 0;
|
|
|
|
t->contained_element_count = 0;
|
2019-02-15 18:36:00 +03:00
|
|
|
t->contained_element_record_length = 0;
|
2014-04-23 17:42:42 +04:00
|
|
|
SMBIOS_TABLE_SET_STR(3, sku_number_str, type3.sku);
|
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
}
|
|
|
|
|
2024-03-14 18:22:54 +03:00
|
|
|
static void smbios_build_type_4_table(MachineState *ms, unsigned instance,
|
2024-03-14 18:22:58 +03:00
|
|
|
SmbiosEntryPointType ep_type,
|
|
|
|
Error **errp)
|
2014-04-23 17:42:42 +04:00
|
|
|
{
|
|
|
|
char sock_str[128];
|
2022-10-11 14:17:27 +03:00
|
|
|
size_t tbl_len = SMBIOS_TYPE_4_LEN_V28;
|
2023-06-28 16:54:36 +03:00
|
|
|
unsigned threads_per_socket;
|
2023-06-28 16:54:37 +03:00
|
|
|
unsigned cores_per_socket;
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2024-03-14 18:22:54 +03:00
|
|
|
if (ep_type == SMBIOS_ENTRY_POINT_TYPE_64) {
|
2022-10-11 14:17:27 +03:00
|
|
|
tbl_len = SMBIOS_TYPE_4_LEN_V30;
|
|
|
|
}
|
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_PRE_SIZE(4, T4_BASE + instance,
|
|
|
|
true, tbl_len); /* required */
|
2014-04-23 17:42:42 +04: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 21:42:26 +03:00
|
|
|
t->processor_family = 0xfe; /* use Processor Family 2 field */
|
2014-04-23 17:42:42 +04:00
|
|
|
SMBIOS_TABLE_SET_STR(4, processor_manufacturer_str, type4.manufacturer);
|
2022-01-25 19:31:18 +03: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 17:42:42 +04:00
|
|
|
SMBIOS_TABLE_SET_STR(4, processor_version_str, type4.version);
|
|
|
|
t->voltage = 0;
|
2014-05-19 18:09:53 +04:00
|
|
|
t->external_clock = cpu_to_le16(0); /* Unknown */
|
2020-08-06 06:56:33 +03:00
|
|
|
t->max_speed = cpu_to_le16(type4.max_speed);
|
|
|
|
t->current_speed = cpu_to_le16(type4.current_speed);
|
2014-04-23 17:42:42 +04:00
|
|
|
t->status = 0x41; /* Socket populated, CPU enabled */
|
|
|
|
t->processor_upgrade = 0x01; /* Other */
|
2014-05-19 18:09:53 +04: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 17:42:42 +04: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 14:17:27 +03:00
|
|
|
|
2023-06-28 16:54:36 +03:00
|
|
|
threads_per_socket = machine_topo_get_threads_per_socket(ms);
|
2023-06-28 16:54:37 +03:00
|
|
|
cores_per_socket = machine_topo_get_cores_per_socket(ms);
|
2023-06-28 16:54:36 +03:00
|
|
|
|
2023-06-28 16:54:37 +03:00
|
|
|
t->core_count = (cores_per_socket > 255) ? 0xFF : cores_per_socket;
|
2022-10-11 14:17:27 +03:00
|
|
|
t->core_enabled = t->core_count;
|
|
|
|
|
2023-06-28 16:54:36 +03:00
|
|
|
t->thread_count = (threads_per_socket > 255) ? 0xFF : threads_per_socket;
|
2022-10-11 14:17:27 +03:00
|
|
|
|
2014-05-19 18:09:53 +04:00
|
|
|
t->processor_characteristics = cpu_to_le16(0x02); /* Unknown */
|
2024-01-23 21:42:26 +03:00
|
|
|
t->processor_family2 = cpu_to_le16(type4.processor_family);
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2023-02-23 15:57:47 +03:00
|
|
|
if (tbl_len == SMBIOS_TYPE_4_LEN_V30) {
|
2023-06-28 16:54:37 +03:00
|
|
|
t->core_count2 = t->core_enabled2 = cpu_to_le16(cores_per_socket);
|
2023-06-28 16:54:36 +03:00
|
|
|
t->thread_count2 = cpu_to_le16(threads_per_socket);
|
2024-03-14 18:22:58 +03:00
|
|
|
} else if (t->core_count == 0xFF || t->thread_count == 0xFF) {
|
|
|
|
error_setg(errp, "SMBIOS 2.0 doesn't support number of processor "
|
|
|
|
"cores/threads more than 255, use "
|
|
|
|
"-machine smbios-entry-point-type=64 option to enable "
|
|
|
|
"SMBIOS 3.0 support");
|
|
|
|
return;
|
2023-02-23 15:57:47 +03:00
|
|
|
}
|
|
|
|
|
2014-04-23 17:42:42 +04: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 16:51:53 +03: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++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-02-21 20:00:27 +03:00
|
|
|
static void smbios_build_type_9_table(Error **errp)
|
2024-02-21 20:00:26 +03:00
|
|
|
{
|
|
|
|
unsigned instance = 0;
|
|
|
|
struct type9_instance *t9;
|
|
|
|
|
|
|
|
QTAILQ_FOREACH(t9, &type9, next) {
|
|
|
|
SMBIOS_BUILD_TABLE_PRE(9, T9_BASE + instance, true);
|
|
|
|
|
|
|
|
SMBIOS_TABLE_SET_STR(9, slot_designation, t9->slot_designation);
|
|
|
|
t->slot_type = t9->slot_type;
|
|
|
|
t->slot_data_bus_width = t9->slot_data_bus_width;
|
|
|
|
t->current_usage = t9->current_usage;
|
|
|
|
t->slot_length = t9->slot_length;
|
|
|
|
t->slot_id = t9->slot_id;
|
|
|
|
t->slot_characteristics1 = t9->slot_characteristics1;
|
|
|
|
t->slot_characteristics2 = t9->slot_characteristics2;
|
|
|
|
|
2024-02-21 20:00:27 +03:00
|
|
|
if (t9->pcidev) {
|
|
|
|
PCIDevice *pdev = NULL;
|
|
|
|
int rc = pci_qdev_find_device(t9->pcidev, &pdev);
|
|
|
|
if (rc != 0) {
|
|
|
|
error_setg(errp,
|
|
|
|
"No PCI device %s for SMBIOS type 9 entry %s",
|
|
|
|
t9->pcidev, t9->slot_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 9 entry for PCI device %s: "
|
|
|
|
"not attached to the root bus",
|
|
|
|
t9->pcidev);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
t->segment_group_number = cpu_to_le16(0);
|
|
|
|
t->bus_number = pci_dev_bus_num(pdev);
|
|
|
|
t->device_number = pdev->devfn;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Per SMBIOS spec, For slots that are not of the PCI, AGP, PCI-X,
|
|
|
|
* or PCI-Express type that do not have bus/device/function
|
|
|
|
* information, 0FFh should be populated in the fields of Segment
|
|
|
|
* Group Number, Bus Number, Device/Function Number.
|
|
|
|
*/
|
|
|
|
t->segment_group_number = 0xff;
|
|
|
|
t->bus_number = 0xff;
|
|
|
|
t->device_number = 0xff;
|
|
|
|
}
|
|
|
|
|
2024-02-21 20:00:26 +03:00
|
|
|
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 23:51:36 +03:00
|
|
|
static void smbios_build_type_11_table(void)
|
|
|
|
{
|
|
|
|
char count_str[128];
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
if (type11.nvalues == 0) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2022-02-23 17:33:20 +03: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 23:51:36 +03: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 16:38:02 +03: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 23:51:36 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
}
|
|
|
|
|
2014-04-23 17:42:42 +04:00
|
|
|
#define MAX_T16_STD_SZ 0x80000000 /* 2T in Kilobytes */
|
|
|
|
|
|
|
|
static void smbios_build_type_16_table(unsigned dimm_cnt)
|
|
|
|
{
|
2014-11-05 09:19:54 +03:00
|
|
|
uint64_t size_kb;
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2022-02-23 17:33:20 +03:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(16, T16_BASE, true); /* required */
|
2014-04-23 17:42:42 +04:00
|
|
|
|
|
|
|
t->location = 0x01; /* Other */
|
|
|
|
t->use = 0x03; /* System memory */
|
|
|
|
t->error_correction = 0x06; /* Multi-bit ECC (for Microsoft, per SeaBIOS) */
|
2020-10-28 13:22:23 +03:00
|
|
|
size_kb = QEMU_ALIGN_UP(current_machine->ram_size, KiB) / KiB;
|
2014-04-23 17:42:42 +04:00
|
|
|
if (size_kb < MAX_T16_STD_SZ) {
|
2014-05-19 18:09:53 +04:00
|
|
|
t->maximum_capacity = cpu_to_le32(size_kb);
|
|
|
|
t->extended_maximum_capacity = cpu_to_le64(0);
|
2014-04-23 17:42:42 +04:00
|
|
|
} else {
|
2014-05-19 18:09:53 +04:00
|
|
|
t->maximum_capacity = cpu_to_le32(MAX_T16_STD_SZ);
|
2020-10-28 13:22:23 +03:00
|
|
|
t->extended_maximum_capacity = cpu_to_le64(current_machine->ram_size);
|
2014-04-23 17:42:42 +04:00
|
|
|
}
|
2014-05-19 18:09:53 +04: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 17:42:42 +04: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 09:19:54 +03:00
|
|
|
static void smbios_build_type_17_table(unsigned instance, uint64_t size)
|
2014-04-23 17:42:42 +04:00
|
|
|
{
|
|
|
|
char loc_str[128];
|
2014-11-05 09:19:54 +03:00
|
|
|
uint64_t size_mb;
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2022-02-23 17:33:20 +03:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(17, T17_BASE + instance, true); /* required */
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2014-05-19 18:09:53 +04: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 15:42:02 +03:00
|
|
|
size_mb = QEMU_ALIGN_UP(size, MiB) / MiB;
|
2014-04-23 17:42:42 +04:00
|
|
|
if (size_mb < MAX_T17_STD_SZ) {
|
2014-05-19 18:09:53 +04:00
|
|
|
t->size = cpu_to_le16(size_mb);
|
|
|
|
t->extended_size = cpu_to_le32(0);
|
2014-04-23 17:42:42 +04:00
|
|
|
} else {
|
|
|
|
assert(size_mb < MAX_T17_EXT_SZ);
|
2014-05-19 18:09:53 +04:00
|
|
|
t->size = cpu_to_le16(MAX_T17_STD_SZ);
|
|
|
|
t->extended_size = cpu_to_le32(size_mb);
|
2014-04-23 17:42:42 +04: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 18:09:53 +04:00
|
|
|
t->type_detail = cpu_to_le16(0x02); /* Other */
|
2015-03-11 20:58:01 +03:00
|
|
|
t->speed = cpu_to_le16(type17.speed);
|
2014-04-23 17:42:42 +04: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 20:58:01 +03:00
|
|
|
t->configured_clock_speed = t->speed; /* reuse value for max speed */
|
2014-05-19 18:09:55 +04: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 17:42:42 +04:00
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
}
|
|
|
|
|
2022-02-23 17:33:21 +03:00
|
|
|
static void smbios_build_type_19_table(unsigned instance, unsigned offset,
|
2014-11-05 09:19:54 +03:00
|
|
|
uint64_t start, uint64_t size)
|
2014-04-23 17:42:42 +04:00
|
|
|
{
|
2014-11-05 09:19:54 +03:00
|
|
|
uint64_t end, start_kb, end_kb;
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2022-02-23 17:33:21 +03:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(19, T19_BASE + offset + instance,
|
|
|
|
true); /* required */
|
2014-04-23 17:42:42 +04:00
|
|
|
|
|
|
|
end = start + size - 1;
|
|
|
|
assert(end > start);
|
2018-06-25 15:42:02 +03:00
|
|
|
start_kb = start / KiB;
|
|
|
|
end_kb = end / KiB;
|
2014-04-23 17:42:42 +04:00
|
|
|
if (start_kb < UINT32_MAX && end_kb < UINT32_MAX) {
|
2014-05-19 18:09:53 +04: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 17:42:42 +04:00
|
|
|
} else {
|
2014-05-19 18:09:53 +04: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 17:42:42 +04:00
|
|
|
}
|
2014-05-19 18:09:53 +04:00
|
|
|
t->memory_array_handle = cpu_to_le16(0x1000); /* Type 16 above */
|
2014-04-23 17:42:42 +04:00
|
|
|
t->partition_width = 1; /* One device per row */
|
|
|
|
|
|
|
|
SMBIOS_BUILD_TABLE_POST;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void smbios_build_type_32_table(void)
|
|
|
|
{
|
2022-02-23 17:33:20 +03:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(32, T32_BASE, true); /* required */
|
2014-04-23 17:42:42 +04: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 20:11:38 +03: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 17:33:20 +03: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 20:11:38 +03: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 17:42:42 +04:00
|
|
|
static void smbios_build_type_127_table(void)
|
|
|
|
{
|
2022-02-23 17:33:20 +03:00
|
|
|
SMBIOS_BUILD_TABLE_PRE(127, T127_BASE, true); /* required */
|
2014-04-23 17:42:42 +04: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 17:42:40 +04:00
|
|
|
#define SMBIOS_SET_DEFAULT(field, value) \
|
|
|
|
if (!field) { \
|
|
|
|
field = value; \
|
|
|
|
}
|
|
|
|
|
2024-01-23 21:42:27 +03:00
|
|
|
void smbios_set_default_processor_family(uint16_t processor_family)
|
|
|
|
{
|
|
|
|
if (type4.processor_family <= 0x01) {
|
|
|
|
type4.processor_family = processor_family;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-04-23 17:42:40 +04:00
|
|
|
void smbios_set_defaults(const char *manufacturer, const char *product,
|
2024-03-27 12:08:05 +03:00
|
|
|
const char *version)
|
2014-04-23 17:42:40 +04:00
|
|
|
{
|
2014-04-23 17:42:42 +04:00
|
|
|
smbios_have_defaults = true;
|
|
|
|
|
2024-03-14 18:22:51 +03:00
|
|
|
SMBIOS_SET_DEFAULT(smbios_type1.manufacturer, manufacturer);
|
|
|
|
SMBIOS_SET_DEFAULT(smbios_type1.product, product);
|
|
|
|
SMBIOS_SET_DEFAULT(smbios_type1.version, version);
|
2014-04-23 17:42:42 +04: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);
|
|
|
|
}
|
|
|
|
|
2024-03-14 18:22:54 +03:00
|
|
|
static void smbios_entry_point_setup(SmbiosEntryPointType ep_type)
|
2014-04-23 17:42:42 +04:00
|
|
|
{
|
2024-03-14 18:22:54 +03:00
|
|
|
switch (ep_type) {
|
2021-10-26 18:10:58 +03:00
|
|
|
case SMBIOS_ENTRY_POINT_TYPE_32:
|
2015-09-07 12:39:28 +03: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 18:10:58 +03:00
|
|
|
case SMBIOS_ENTRY_POINT_TYPE_64:
|
2015-09-07 12:39:28 +03: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 17:42:42 +04:00
|
|
|
}
|
|
|
|
|
2024-03-14 18:22:57 +03:00
|
|
|
static bool smbios_get_tables_ep(MachineState *ms,
|
2024-03-14 18:22:54 +03:00
|
|
|
SmbiosEntryPointType ep_type,
|
2019-05-18 23:54:20 +03:00
|
|
|
const struct smbios_phys_mem_area *mem_array,
|
2015-08-12 05:08:19 +03: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 20:11:38 +03:00
|
|
|
uint8_t **anchor, size_t *anchor_len,
|
|
|
|
Error **errp)
|
2014-04-23 17:42:42 +04:00
|
|
|
{
|
2022-02-23 17:33:21 +03:00
|
|
|
unsigned i, dimm_cnt, offset;
|
smbios: make memory device size configurable per Machine
Currently QEMU describes initial[1] RAM* in SMBIOS as a series of
virtual DIMMs (capped at 16Gb max) using type 17 structure entries.
Which is fine for the most cases. However when starting guest
with terabytes of RAM this leads to too many memory device
structures, which eventually upsets linux kernel as it reserves
only 64K for these entries and when that border is crossed out
it runs out of reserved memory.
Instead of partitioning initial RAM on 16Gb DIMMs, use maximum
possible chunk size that SMBIOS spec allows[2]. Which lets
encode RAM in lower 31 bits of 32bit field (which amounts upto
2047Tb per DIMM).
As result initial RAM will generate only one type 17 structure
until host/guest reach ability to use more RAM in the future.
Compat changes:
We can't unconditionally change chunk size as it will break
QEMU<->guest ABI (and migration). Thus introduce a new machine
class field that would let older versioned machines to use
legacy 16Gb chunks, while new(er) machine type[s] use maximum
possible chunk size.
PS:
While it might seem to be risky to rise max entry size this large
(much beyond of what current physical RAM modules support),
I'd not expect it causing much issues, modulo uncovering bugs
in software running within guest. And those should be fixed
on guest side to handle SMBIOS spec properly, especially if
guest is expected to support so huge RAM configs.
In worst case, QEMU can reduce chunk size later if we would
care enough about introducing a workaround for some 'unfixable'
guest OS, either by fixing up the next machine type or
giving users a CLI option to customize it.
1) Initial RAM - is RAM configured with help '-m SIZE' CLI option/
implicitly defined by machine. It doesn't include memory
configured with help of '-device' option[s] (pcdimm,nvdimm,...)
2) SMBIOS 3.1.0 7.18.5 Memory Device — Extended Size
PS:
* tested on 8Tb host with RHEL6 guest, which seems to parse
type 17 SMBIOS table entries correctly (according to 'dmidecode').
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20240715122417.4059293-1-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-15 15:24:17 +03:00
|
|
|
MachineClass *mc = MACHINE_GET_CLASS(ms);
|
2024-03-14 18:22:57 +03:00
|
|
|
ERRP_GUARD();
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2024-03-14 18:22:54 +03:00
|
|
|
assert(ep_type == SMBIOS_ENTRY_POINT_TYPE_32 ||
|
|
|
|
ep_type == SMBIOS_ENTRY_POINT_TYPE_64);
|
|
|
|
|
2024-03-14 18:22:48 +03:00
|
|
|
g_free(smbios_tables);
|
2024-03-14 18:22:55 +03:00
|
|
|
smbios_type4_count = 0;
|
2024-03-14 18:22:48 +03:00
|
|
|
smbios_tables = g_memdup2(usr_blobs, usr_blobs_len);
|
|
|
|
smbios_tables_len = usr_blobs_len;
|
|
|
|
smbios_table_max = usr_table_max;
|
|
|
|
smbios_table_cnt = usr_table_cnt;
|
2024-03-14 18:22:47 +03:00
|
|
|
|
2024-03-14 18:22:48 +03:00
|
|
|
smbios_build_type_0_table();
|
|
|
|
smbios_build_type_1_table();
|
|
|
|
smbios_build_type_2_table();
|
|
|
|
smbios_build_type_3_table();
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2024-03-14 18:22:48 +03:00
|
|
|
assert(ms->smp.sockets >= 1);
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2024-03-14 18:22:48 +03:00
|
|
|
for (i = 0; i < ms->smp.sockets; i++) {
|
2024-03-14 18:22:58 +03:00
|
|
|
smbios_build_type_4_table(ms, i, ep_type, errp);
|
|
|
|
if (*errp) {
|
|
|
|
goto err_exit;
|
|
|
|
}
|
2024-03-14 18:22:48 +03:00
|
|
|
}
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2024-03-14 18:22:48 +03:00
|
|
|
smbios_build_type_8_table();
|
|
|
|
smbios_build_type_9_table(errp);
|
|
|
|
smbios_build_type_11_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 23:51:36 +03:00
|
|
|
|
smbios: make memory device size configurable per Machine
Currently QEMU describes initial[1] RAM* in SMBIOS as a series of
virtual DIMMs (capped at 16Gb max) using type 17 structure entries.
Which is fine for the most cases. However when starting guest
with terabytes of RAM this leads to too many memory device
structures, which eventually upsets linux kernel as it reserves
only 64K for these entries and when that border is crossed out
it runs out of reserved memory.
Instead of partitioning initial RAM on 16Gb DIMMs, use maximum
possible chunk size that SMBIOS spec allows[2]. Which lets
encode RAM in lower 31 bits of 32bit field (which amounts upto
2047Tb per DIMM).
As result initial RAM will generate only one type 17 structure
until host/guest reach ability to use more RAM in the future.
Compat changes:
We can't unconditionally change chunk size as it will break
QEMU<->guest ABI (and migration). Thus introduce a new machine
class field that would let older versioned machines to use
legacy 16Gb chunks, while new(er) machine type[s] use maximum
possible chunk size.
PS:
While it might seem to be risky to rise max entry size this large
(much beyond of what current physical RAM modules support),
I'd not expect it causing much issues, modulo uncovering bugs
in software running within guest. And those should be fixed
on guest side to handle SMBIOS spec properly, especially if
guest is expected to support so huge RAM configs.
In worst case, QEMU can reduce chunk size later if we would
care enough about introducing a workaround for some 'unfixable'
guest OS, either by fixing up the next machine type or
giving users a CLI option to customize it.
1) Initial RAM - is RAM configured with help '-m SIZE' CLI option/
implicitly defined by machine. It doesn't include memory
configured with help of '-device' option[s] (pcdimm,nvdimm,...)
2) SMBIOS 3.1.0 7.18.5 Memory Device — Extended Size
PS:
* tested on 8Tb host with RHEL6 guest, which seems to parse
type 17 SMBIOS table entries correctly (according to 'dmidecode').
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20240715122417.4059293-1-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-15 15:24:17 +03:00
|
|
|
#define GET_DIMM_SZ ((i < dimm_cnt - 1) ? mc->smbios_memory_device_size \
|
|
|
|
: ((current_machine->ram_size - 1) % mc->smbios_memory_device_size) + 1)
|
2014-04-23 17:42:42 +04:00
|
|
|
|
smbios: make memory device size configurable per Machine
Currently QEMU describes initial[1] RAM* in SMBIOS as a series of
virtual DIMMs (capped at 16Gb max) using type 17 structure entries.
Which is fine for the most cases. However when starting guest
with terabytes of RAM this leads to too many memory device
structures, which eventually upsets linux kernel as it reserves
only 64K for these entries and when that border is crossed out
it runs out of reserved memory.
Instead of partitioning initial RAM on 16Gb DIMMs, use maximum
possible chunk size that SMBIOS spec allows[2]. Which lets
encode RAM in lower 31 bits of 32bit field (which amounts upto
2047Tb per DIMM).
As result initial RAM will generate only one type 17 structure
until host/guest reach ability to use more RAM in the future.
Compat changes:
We can't unconditionally change chunk size as it will break
QEMU<->guest ABI (and migration). Thus introduce a new machine
class field that would let older versioned machines to use
legacy 16Gb chunks, while new(er) machine type[s] use maximum
possible chunk size.
PS:
While it might seem to be risky to rise max entry size this large
(much beyond of what current physical RAM modules support),
I'd not expect it causing much issues, modulo uncovering bugs
in software running within guest. And those should be fixed
on guest side to handle SMBIOS spec properly, especially if
guest is expected to support so huge RAM configs.
In worst case, QEMU can reduce chunk size later if we would
care enough about introducing a workaround for some 'unfixable'
guest OS, either by fixing up the next machine type or
giving users a CLI option to customize it.
1) Initial RAM - is RAM configured with help '-m SIZE' CLI option/
implicitly defined by machine. It doesn't include memory
configured with help of '-device' option[s] (pcdimm,nvdimm,...)
2) SMBIOS 3.1.0 7.18.5 Memory Device — Extended Size
PS:
* tested on 8Tb host with RHEL6 guest, which seems to parse
type 17 SMBIOS table entries correctly (according to 'dmidecode').
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20240715122417.4059293-1-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-15 15:24:17 +03:00
|
|
|
dimm_cnt = QEMU_ALIGN_UP(current_machine->ram_size,
|
|
|
|
mc->smbios_memory_device_size) /
|
|
|
|
mc->smbios_memory_device_size;
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2024-03-14 18:22:48 +03:00
|
|
|
/*
|
|
|
|
* The offset determines if we need to keep additional space between
|
|
|
|
* 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;
|
2022-02-23 17:33:21 +03:00
|
|
|
|
2024-03-14 18:22:48 +03:00
|
|
|
smbios_build_type_16_table(dimm_cnt);
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2024-03-14 18:22:48 +03:00
|
|
|
for (i = 0; i < dimm_cnt; i++) {
|
|
|
|
smbios_build_type_17_table(i, GET_DIMM_SZ);
|
|
|
|
}
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2024-03-14 18:22:48 +03:00
|
|
|
for (i = 0; i < mem_array_size; i++) {
|
|
|
|
smbios_build_type_19_table(i, offset, mem_array[i].address,
|
|
|
|
mem_array[i].length);
|
|
|
|
}
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2024-03-14 18:22:48 +03: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));
|
2022-02-23 17:33:22 +03:00
|
|
|
|
2024-03-14 18:22:48 +03:00
|
|
|
smbios_build_type_32_table();
|
|
|
|
smbios_build_type_38_table();
|
|
|
|
smbios_build_type_41_table(errp);
|
|
|
|
smbios_build_type_127_table();
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2024-03-14 18:22:53 +03:00
|
|
|
if (!smbios_check_type4_count(ms->smp.sockets, errp)) {
|
|
|
|
goto err_exit;
|
|
|
|
}
|
2024-03-14 18:22:54 +03:00
|
|
|
if (!smbios_validate_table(ep_type, errp)) {
|
2024-03-14 18:22:53 +03:00
|
|
|
goto err_exit;
|
|
|
|
}
|
2024-03-14 18:22:54 +03:00
|
|
|
smbios_entry_point_setup(ep_type);
|
2014-04-23 17:42:42 +04:00
|
|
|
|
|
|
|
/* 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 12:39:28 +03: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();
|
|
|
|
}
|
2024-03-14 18:22:53 +03:00
|
|
|
|
2024-03-14 18:22:57 +03:00
|
|
|
return true;
|
2024-03-14 18:22:53 +03:00
|
|
|
err_exit:
|
|
|
|
g_free(smbios_tables);
|
|
|
|
smbios_tables = NULL;
|
2024-03-14 18:22:57 +03:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
void smbios_get_tables(MachineState *ms,
|
|
|
|
SmbiosEntryPointType ep_type,
|
|
|
|
const struct smbios_phys_mem_area *mem_array,
|
|
|
|
const unsigned int mem_array_size,
|
|
|
|
uint8_t **tables, size_t *tables_len,
|
|
|
|
uint8_t **anchor, size_t *anchor_len,
|
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
Error *local_err = NULL;
|
|
|
|
bool is_valid;
|
|
|
|
ERRP_GUARD();
|
|
|
|
|
|
|
|
switch (ep_type) {
|
|
|
|
case SMBIOS_ENTRY_POINT_TYPE_AUTO:
|
|
|
|
case SMBIOS_ENTRY_POINT_TYPE_32:
|
|
|
|
is_valid = smbios_get_tables_ep(ms, SMBIOS_ENTRY_POINT_TYPE_32,
|
|
|
|
mem_array, mem_array_size,
|
|
|
|
tables, tables_len,
|
|
|
|
anchor, anchor_len,
|
|
|
|
&local_err);
|
|
|
|
if (is_valid || ep_type != SMBIOS_ENTRY_POINT_TYPE_AUTO) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* fall through in case AUTO endpoint is selected and
|
|
|
|
* SMBIOS 2.x tables can't be generated, to try if SMBIOS 3.x
|
|
|
|
* tables would work
|
|
|
|
*/
|
|
|
|
case SMBIOS_ENTRY_POINT_TYPE_64:
|
|
|
|
error_free(local_err);
|
|
|
|
local_err = NULL;
|
|
|
|
is_valid = smbios_get_tables_ep(ms, SMBIOS_ENTRY_POINT_TYPE_64,
|
|
|
|
mem_array, mem_array_size,
|
|
|
|
tables, tables_len,
|
|
|
|
anchor, anchor_len,
|
|
|
|
&local_err);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
if (!is_valid) {
|
|
|
|
error_propagate(errp, local_err);
|
|
|
|
}
|
2014-04-23 17:42:40 +04: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 17:18:31 +04: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 17:18:29 +04: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 22:59:56 +04: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 23:51:36 +03:00
|
|
|
|
|
|
|
struct opt_list {
|
|
|
|
size_t *ndest;
|
2020-09-23 16:38:02 +03: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 23:51:36 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
static int save_opt_one(void *opaque,
|
|
|
|
const char *name, const char *value,
|
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
struct opt_list *opt = opaque;
|
|
|
|
|
2020-09-23 16:38:02 +03: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 18:27:42 +03:00
|
|
|
qemu_close(fd);
|
2020-09-23 16:38:02 +03:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (memchr(buf, '\0', ret)) {
|
|
|
|
error_setg(errp, "NUL in OEM strings value in %s", value);
|
2020-10-30 18:27:42 +03:00
|
|
|
qemu_close(fd);
|
2020-09-23 16:38:02 +03:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
g_byte_array_append(data, (guint8 *)buf, ret);
|
|
|
|
}
|
|
|
|
|
2020-10-30 18:27:42 +03:00
|
|
|
qemu_close(fd);
|
2020-09-23 16:38:02 +03: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 23:51:36 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-09-23 16:38:02 +03: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 23:51:36 +03:00
|
|
|
{
|
|
|
|
struct opt_list opt = {
|
2020-09-23 16:38:02 +03: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 23:51:36 +03:00
|
|
|
};
|
2020-09-23 16:38:02 +03: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 23:51:36 +03:00
|
|
|
}
|
|
|
|
|
2016-12-22 18:18:28 +03: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 22:59:56 +04:00
|
|
|
{
|
2013-08-16 17:18:29 +04: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 22:59:56 +04:00
|
|
|
|
2013-08-16 17:18:29 +04: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 22:59:56 +04:00
|
|
|
struct smbios_structure_header *header;
|
2024-03-14 18:22:48 +03:00
|
|
|
size_t size;
|
2013-08-16 17:18:29 +04: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 19:06:02 +03:00
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_file_opts, errp)) {
|
2018-10-17 11:26:35 +03: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 22:59:56 +04:00
|
|
|
|
2013-08-16 17:18:29 +04:00
|
|
|
size = get_image_size(val);
|
2009-07-31 21:49:14 +04:00
|
|
|
if (size == -1 || size < sizeof(struct smbios_structure_header)) {
|
2018-10-17 11:26:35 +03: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 22:59:56 +04:00
|
|
|
}
|
|
|
|
|
2014-04-23 17:42:42 +04: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).
|
|
|
|
*/
|
2024-03-14 18:22:48 +03:00
|
|
|
usr_blobs = g_realloc(usr_blobs, usr_blobs_len + size);
|
|
|
|
header = (struct smbios_structure_header *)(usr_blobs +
|
|
|
|
usr_blobs_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 22:59:56 +04:00
|
|
|
|
2018-12-14 16:30:50 +03:00
|
|
|
if (load_image_size(val, (uint8_t *)header, size) != size) {
|
2018-10-17 11:26:35 +03: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 22:59:56 +04:00
|
|
|
}
|
|
|
|
|
2022-09-05 13:32:44 +03:00
|
|
|
if (header->type <= SMBIOS_MAX_TYPE) {
|
2024-03-14 18:22:51 +03:00
|
|
|
if (test_bit(header->type, smbios_have_fields_bitmap)) {
|
2022-09-05 13:32:44 +03:00
|
|
|
error_setg(errp,
|
|
|
|
"can't load type %d struct, fields already specified!",
|
|
|
|
header->type);
|
|
|
|
return;
|
|
|
|
}
|
2024-03-14 18:22:51 +03:00
|
|
|
set_bit(header->type, smbios_have_binfile_bitmap);
|
2014-04-23 17:42:41 +04:00
|
|
|
}
|
|
|
|
|
2009-07-31 21:49:14 +04: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 22:59:56 +04:00
|
|
|
|
2024-03-14 18:22:50 +03:00
|
|
|
/*
|
|
|
|
* preserve blob size for legacy mode so it could build its
|
|
|
|
* blobs flavor from 'usr_blobs'
|
|
|
|
*/
|
|
|
|
smbios_add_usr_blob_size(size);
|
|
|
|
|
2024-03-14 18:22:48 +03:00
|
|
|
usr_blobs_len += size;
|
|
|
|
if (size > usr_table_max) {
|
|
|
|
usr_table_max = size;
|
2014-04-23 17:42:42 +04:00
|
|
|
}
|
2024-03-14 18:22:48 +03:00
|
|
|
usr_table_cnt++;
|
2014-04-23 17:42:42 +04:00
|
|
|
|
2013-08-16 17:18:28 +04: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 22:59:56 +04:00
|
|
|
}
|
|
|
|
|
2013-08-16 17:18:29 +04:00
|
|
|
val = qemu_opt_get(opts, "type");
|
|
|
|
if (val) {
|
|
|
|
unsigned long type = strtoul(val, NULL, 0);
|
|
|
|
|
2014-04-23 17:42:41 +04:00
|
|
|
if (type > SMBIOS_MAX_TYPE) {
|
2018-10-17 11:26:35 +03:00
|
|
|
error_setg(errp, "out of range!");
|
|
|
|
return;
|
2014-04-23 17:42:41 +04:00
|
|
|
}
|
|
|
|
|
2024-03-14 18:22:51 +03:00
|
|
|
if (test_bit(type, smbios_have_binfile_bitmap)) {
|
2018-10-17 11:26:35 +03:00
|
|
|
error_setg(errp, "can't add fields, binary file already loaded!");
|
|
|
|
return;
|
2014-04-23 17:42:41 +04:00
|
|
|
}
|
2024-03-14 18:22:51 +03:00
|
|
|
set_bit(type, smbios_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 17:18:31 +04: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 22:59:56 +04: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 19:06:02 +03:00
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type0_opts, errp)) {
|
2018-10-17 11:26:35 +03:00
|
|
|
return;
|
|
|
|
}
|
2024-03-14 18:22:51 +03:00
|
|
|
save_opt(&smbios_type0.vendor, opts, "vendor");
|
|
|
|
save_opt(&smbios_type0.version, opts, "version");
|
|
|
|
save_opt(&smbios_type0.date, opts, "date");
|
|
|
|
smbios_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 17:18:31 +04:00
|
|
|
|
|
|
|
val = qemu_opt_get(opts, "release");
|
|
|
|
if (val) {
|
2024-03-14 18:22:51 +03:00
|
|
|
if (sscanf(val, "%hhu.%hhu", &smbios_type0.major,
|
|
|
|
&smbios_type0.minor) != 2) {
|
2018-10-17 11:26:35 +03: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 17:18:31 +04:00
|
|
|
}
|
2024-03-14 18:22:51 +03:00
|
|
|
smbios_type0.have_major_minor = true;
|
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 17:18:31 +04:00
|
|
|
}
|
2013-08-16 17:18:28 +04: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 22:59:56 +04: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 19:06:02 +03:00
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type1_opts, errp)) {
|
2018-10-17 11:26:35 +03:00
|
|
|
return;
|
|
|
|
}
|
2024-03-14 18:22:51 +03:00
|
|
|
save_opt(&smbios_type1.manufacturer, opts, "manufacturer");
|
|
|
|
save_opt(&smbios_type1.product, opts, "product");
|
|
|
|
save_opt(&smbios_type1.version, opts, "version");
|
|
|
|
save_opt(&smbios_type1.serial, opts, "serial");
|
|
|
|
save_opt(&smbios_type1.sku, opts, "sku");
|
|
|
|
save_opt(&smbios_type1.family, opts, "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 17:18:31 +04:00
|
|
|
|
|
|
|
val = qemu_opt_get(opts, "uuid");
|
|
|
|
if (val) {
|
2016-09-21 07:27:22 +03:00
|
|
|
if (qemu_uuid_parse(val, &qemu_uuid) != 0) {
|
2018-10-17 11:26:35 +03: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 17:18:31 +04:00
|
|
|
}
|
|
|
|
qemu_uuid_set = true;
|
|
|
|
}
|
2013-08-16 17:18:28 +04:00
|
|
|
return;
|
2014-04-23 17:42:42 +04: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 19:06:02 +03:00
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type2_opts, errp)) {
|
2018-10-17 11:26:35 +03:00
|
|
|
return;
|
|
|
|
}
|
2014-04-23 17:42:42 +04: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 19:06:02 +03:00
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type3_opts, errp)) {
|
2018-10-17 11:26:35 +03:00
|
|
|
return;
|
|
|
|
}
|
2014-04-23 17:42:42 +04: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 19:06:02 +03:00
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type4_opts, errp)) {
|
2018-10-17 11:26:35 +03:00
|
|
|
return;
|
|
|
|
}
|
2014-04-23 17:42:42 +04:00
|
|
|
save_opt(&type4.sock_pfx, opts, "sock_pfx");
|
2024-01-23 21:42:26 +03:00
|
|
|
type4.processor_family = qemu_opt_get_number(opts,
|
|
|
|
"processor-family",
|
|
|
|
0x01 /* Other */);
|
2014-04-23 17:42:42 +04: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 19:31:18 +03: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 06:56:33 +03: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 17:42:42 +04: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 16:51:53 +03:00
|
|
|
case 8:
|
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type8_opts, errp)) {
|
|
|
|
return;
|
|
|
|
}
|
2023-09-22 15:42:02 +03: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 16:51:53 +03:00
|
|
|
return;
|
2024-02-21 20:00:26 +03:00
|
|
|
case 9: {
|
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type9_opts, errp)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
struct type9_instance *t;
|
|
|
|
t = g_new0(struct type9_instance, 1);
|
|
|
|
save_opt(&t->slot_designation, opts, "slot_designation");
|
|
|
|
t->slot_type = qemu_opt_get_number(opts, "slot_type", 0);
|
2024-03-13 01:28:12 +03:00
|
|
|
t->slot_data_bus_width =
|
|
|
|
qemu_opt_get_number(opts, "slot_data_bus_width", 0);
|
2024-02-21 20:00:26 +03:00
|
|
|
t->current_usage = qemu_opt_get_number(opts, "current_usage", 0);
|
|
|
|
t->slot_length = qemu_opt_get_number(opts, "slot_length", 0);
|
|
|
|
t->slot_id = qemu_opt_get_number(opts, "slot_id", 0);
|
2024-03-13 01:28:12 +03:00
|
|
|
t->slot_characteristics1 =
|
|
|
|
qemu_opt_get_number(opts, "slot_characteristics1", 0);
|
|
|
|
t->slot_characteristics2 =
|
|
|
|
qemu_opt_get_number(opts, "slot_characteristics2", 0);
|
2024-02-21 20:00:27 +03:00
|
|
|
save_opt(&t->pcidev, opts, "pcidev");
|
2024-02-21 20:00:26 +03:00
|
|
|
QTAILQ_INSERT_TAIL(&type9, t, next);
|
|
|
|
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 23:51:36 +03: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 19:06:02 +03:00
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type11_opts, errp)) {
|
2018-10-17 11:26:35 +03:00
|
|
|
return;
|
|
|
|
}
|
2020-09-23 16:38:02 +03: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 23:51:36 +03:00
|
|
|
return;
|
2014-04-23 17:42:42 +04: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 19:06:02 +03:00
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type17_opts, errp)) {
|
2018-10-17 11:26:35 +03:00
|
|
|
return;
|
|
|
|
}
|
2014-04-23 17:42:42 +04: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 20:58:01 +03:00
|
|
|
type17.speed = qemu_opt_get_number(opts, "speed", 0);
|
2014-04-23 17:42:42 +04: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 20:11:38 +03:00
|
|
|
case 41: {
|
2023-09-22 15:42:02 +03: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 20:11:38 +03:00
|
|
|
Error *local_err = NULL;
|
|
|
|
|
|
|
|
if (!qemu_opts_validate(opts, qemu_smbios_type41_opts, errp)) {
|
|
|
|
return;
|
|
|
|
}
|
2023-09-22 15:42:02 +03: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 20:11:38 +03:00
|
|
|
if (local_err != NULL) {
|
|
|
|
error_propagate(errp, local_err);
|
2023-09-22 15:42:02 +03: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 20:11:38 +03:00
|
|
|
return;
|
|
|
|
}
|
2023-09-22 15:42:02 +03: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 20:11:38 +03:00
|
|
|
|
2023-09-22 15:42:02 +03: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 20:11:38 +03: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 22:59:56 +04:00
|
|
|
default:
|
2018-10-17 11:26:35 +03: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 22:59:56 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-10-17 11:26:35 +03: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 22:59:56 +04:00
|
|
|
}
|