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://