On 02/18/14 22:08, Laszlo Ersek wrote:
On 02/18/14 20:17, Gabriel L. Somlo wrote:
On Tue, Feb 18, 2014 at 11:21:33AM +0100, Gerd Hoffmann wrote:
Using Fedora 20 live, I collected the SMBIOS table from the guest using "dmidecode --dump-bin", with the unpatched SeaBIOS (dmidecode_pc.bin), SeaBIOS with my patch applied (dmidecode_mac.bin), and again with unpatched SeaBIOS but with "-smbios file=dmidecode_mac.bin" on the QEMU command line (dmidecode_cmdline.bin).
[...]
However, when I compare unmodified SMBIOS against what I get when supplying the patched binary table via command line, I get this:
$ diff dmi_pc.txt dmi_cmdline.txt 2c2
< Reading SMBIOS/DMI data from file dmidecode_pc.bin.
Reading SMBIOS/DMI data from file dmidecode_cmdline.bin.
4c4
< 10 structures occupying 298 bytes.
11 structures occupying 657 bytes.
108,109c108,120 < Handle 0x7F00, DMI type 127, 4 bytes
< End Of Table
Handle 0x5F4D, DMI type 95, 83 bytes Unknown Type Header and Data: 5F 53 4D 5F 32 1F 02 04 4B 00 00 00 00 00 00 00 5F 44 4D 49 5F D2 46 01 20 00 00 00 0B 00 24 00 00 18 00 00 01 02 00 E8 03 00 08 00 00 00 00 00 00 00 00 04 01 00 FF FF 42 6F 63 68 73 00 42 6F 63 68 73 00 30 31 2F 30 31 2F 32 30 31 31 00 00 01 1B 00 Strings: ....
Invalid entry length (0). DMI table is broken! Stop.
No Type 2, no extra fields for Type 17, and a corrupt table to boot.
I had tested this qemu interface with my OVMF SMBIOS patches. It works. (I used a Type 3 table.)
The problem in this case is that you can't just pass in a raw dump from dmidecode. You need to prefix it with "smbios_header":
struct smbios_table { struct smbios_header header; uint8_t data[]; } QEMU_PACKED;
struct smbios_header { uint16_t length; uint8_t type; } QEMU_PACKED;
You need to set "type" to 1 (SMBIOS_TABLE_ENTRY), and set "length" so that it covers the entire "smbios_table" struct (ie. both header and payload, where payload is your SMBIOS table). "length" is little endian.
Oh wait, scratch that, qemu should do this for you.
But, I retested the thing (with my original Type 3 file), and it still seems to work.
-smbios file=/home/virt-images/smbios/type3
000000 03 14 00 03 01 01 00 00 00 03 03 03 02 00 00 00 000010 00 00 00 00 52 65 64 20 48 61 74 00 00
Dumped in the OVMF guest:
Handle 0x0000, DMI type 3, 20 bytes Chassis Information Manufacturer: Red Hat Type: Other Lock: Not Present Version: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: Unknown OEM Information: 0x00000000 Height: Unspecified Number Of Power Cords: Unspecified
What was the exact command line you used?
... Ah, I think I understand. When you issued dmidecode --dump-bin, that dumped *all* of the tables. (--dump-bin is mutually exclusive with --type.) You can't pass multiple tables with one '-smbios file=XXX qemu option. You need separate binary dumps (one per table), and should pass them with one -smbios file=XXX option each.
Thanks Laszlo