blob: 53f58a2bfced2c79ee998123d6fe905942c1fc96 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
|
files: 0.663
device: 0.554
ppc: 0.441
graphic: 0.382
network: 0.358
boot: 0.327
socket: 0.323
mistranslation: 0.317
architecture: 0.306
kernel: 0.298
risc-v: 0.288
register: 0.284
vnc: 0.263
semantic: 0.262
performance: 0.259
arm: 0.258
hypervisor: 0.231
PID: 0.222
x86: 0.213
VMM: 0.212
permissions: 0.212
i386: 0.203
peripherals: 0.188
virtual: 0.186
user-level: 0.182
KVM: 0.177
TCG: 0.165
debug: 0.152
assembly: 0.123
RFE: populate "OEM Strings" (type 11) SMBIOS table strings from regular files
The feature added in
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2d6dcbf93fb01b4a7f45a93d276d4d74b16392dd
and exposed by libvirt as
https://libvirt.org/formatdomain.html#elementsSysinfo
allows the user to specify up to 255 strings in the unofmatted area of the Type 11 SMBIOS table, where each string may be of arbitrary length. This feature is useful for exposing arbitrary text to arbitrary guest components (in particular when strings are prefixed with "application identifiers").
Right now, strings can only be specified on the QEMU command line, which limits the amount of data that can be passed. Please enable users to pass data from regular files too.
For example:
$QEMU -smbios type=11,value=Hello,txtfile=file1.txt,txtfile=file2.txt
where "file1.txt" and "file2.txt" could be text files containing ASCII application prefixes, followed by base64-encoded binary data.
See also: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
See also: https://github.com/puiterwijk/qemu-ovmf-secureboot/issues/25
We'll probably never have resources for this -- nice to have feature, but has not become critical in ~1.5 years. LP doesn't allow me to close the ticket as "Won't Fix", so I'll have to go with "Invalid". (The report is not invalid at all, but the ticket status should *somehow* reflect that we have no resources for working on this.)
Surprise...
https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg03023.html
Discovering the firmware limits was tedious. SeaBIOS limits SMBIOS to 64KB total size due to support for SMBIOS 2.1 spec only, while EDK2 fails a little over 128 KB total size despite supporting SMBIOS 3.0 which should not be limited IIUC
Merged: https://<email address hidden>/
Commits:
https://gitlab.com/qemu-project/qemu/-/commit/bb99f4772f54017490e3356ecbb3df25c5d4537f
https://gitlab.com/qemu-project/qemu/-/commit/10c3666658f53c5ec8fd9ec27cdf5c393ff814a0
https://gitlab.com/qemu-project/qemu/-/commit/48a7ff4d516c92323ca7bd88df90ebb974bc0a9a
Released with QEMU v5.2.0.
|