I previously added support for SMBIOS OEM strings tables but only allowed for data to be passed inline. Potential users indicated they wanted to pass some quite large data blobs which is inconvenient todo inline. Thus I'm adding support for passing the data from a file.
In testing this I discovered the hard way that on x86 we're limited to using the SMBIOS 2.1 entry point currently. This has a maximum size of 0xffff, and if you exceed this all sorts of wierd behaviour happens. QEMU forces SMBIOS 2.1 on x86 because the default SeaBIOS firmware does not support SMBIOS 3.0. The EDK2 firmware supports SMBIOS 3.0 and QEMU defaults to this on the ARM virt machine type. This series adds support for checking the SMBIOS 2.1 limits to protect users from impossible to diagnose problems. There is also a fix needed to SeaBIOS which fails to check for integer overflow when it appends the type 0 table. https://mail.coreboot.org/hyperkitty/list/seab...@seabios.org/thread/3EMIOY= 6YS6MG5UQN3JJJS2A3DJZOVFR6/ IIUC, SMBIOS 3.0 should only be limited by what you can fit into RAM, but in testing, EDK2 appears to hang shortly after the SMBIOS 3.0 data size exceeds 128 KB. I've not spotted an obvious flaw in EDK2 or QEMU, nor do I attempt to enforce a limit in QEMU for SMBIOS 3.0. Changed in v3: - Adjust for qemu_open method signature change Changed in v2: - Drop the patches that allowed choice of SMBIOS 2.1 / 3.0 entry point. There's no compelling reason to need 3.0 on x86 while aarch64 is 3.0 only. Daniel P. Berrang=C3=A9 (3): hw/smbios: support loading OEM strings values from a file hw/smbios: report error if table size is too large qemu-options: document SMBIOS type 11 settings hw/smbios/smbios.c | 85 +++++++++++++++++++++++++++++++++++++++------- qemu-options.hx | 41 ++++++++++++++++++++++ 2 files changed, 113 insertions(+), 13 deletions(-) --=20 2.26.2
