Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU)

[Laszlo Ersek <lersek@redhat.com>]

On 04/01/14 16:39, Kevin O'Connor wrote:
> On Tue, Apr 01, 2014 at 10:40:00AM +0200, Laszlo Ersek wrote:
>> On 03/31/14 22:18, Gabriel L. Somlo wrote:
>>> The only sticking point remaining would be who gets to generate the
>>> Type 0 (BIOS Information) table and when, which is something QEMU
>>> should arguably NOT be doing on behalf of SeaBIOS (or OVMF, or ...).
>>>
>>> I guess everyone's busy with QEMU 2.0, so I'll keep playing with this
>>> stuff on my own and bring it up again afterwards.
>>>
>>> Obviously, more comments and feedback are welcome at any time, should
>>> there be any interest :)
>>
>> Sorry I can follow this discussion only intermittently.
>>
>> - I think OVMF would be fine with the Type 0 table as-is (it has a
>> default table and adheres to field-level patches). Full tables for other
>> types would be welcome.
> 
> When SeaBIOS generates the smbios table, it creates a hardcoded type 0
> sub-table.  (See SeaBIOS code src/fw/smbios.c:smbios_init_type_0.)  If
> OVMF is okay with the same hardcodes, then I'd suggest QEMU create the
> table the same way SeaBIOS currently does.

In SeaBIOS,

    if (!get_field(0, offsetof(struct smbios_type_0,
                               bios_characteristics_extension_bytes),
                   &p->bios_characteristics_extension_bytes)) {
        p->bios_characteristics_extension_bytes[0] = 0;
        /* Enable targeted content distribution. Needed for SVVP */
        p->bios_characteristics_extension_bytes[1] = 4;
    }

bit 2 of the BIOS Characteristics Extension Byte 2 (7.1.2.2) is set, for
"Enable Targeted Content Distribution".

In OVMF, the same byte has the following bits set:

Bit 3 -- UEFI Specification is supported.
Bit 4 -- The SMBIOS table describes a virtual machine. (If this bit is
         not set, no inference can be made about the virtuality of the
         system.)

I have nothing against bit 2 (I didn't include it because I had no clue
what it meant, but we can certainly set that bit down the road). Bit 3
would be wrong for SeaBIOS, and it would be wrong to leave clear for
OVMF. Bit 4 would be wrong for SeaBIOS (as a static default), but is
correct (and very nice, although not necessary) for OVMF.

Gerd posted a textual comparison before (with dmidecode):

  http://thread.gmane.org/gmane.comp.emulators.qemu/260804/focus=261248

But I'm including a textual diff too (RHEL-7 host, RHEL-7 guests):

> --- seabios-rhel7.txt	2014-04-01 17:39:49.148601405 +0200
> +++ ovmf-rhel7.txt	2014-04-01 17:40:01.075658204 +0200
> @@ -1,128 +1,34 @@
>  # dmidecode 2.12
> -SMBIOS 2.4 present.
> -11 structures occupying 369 bytes.
> -Table at 0x000FDD80.
> +# SMBIOS entry point at 0x3fed8000
> +SMBIOS 2.7 present.
> +3 structures occupying 185 bytes.
> +Table at 0x3FED7000.
>
>  Handle 0x0000, DMI type 0, 24 bytes
>  BIOS Information
> -	Vendor: Bochs
> -	Version: Bochs
> -	Release Date: 01/01/2011
> +	Vendor: EFI Development Kit II / OVMF
> +	Version: 0.1
> +	Release Date: 06/03/2013
>  	Address: 0xE8000
>  	Runtime Size: 96 kB
>  	ROM Size: 64 kB
>  	Characteristics:
>  		BIOS characteristics not supported
> -		Targeted content distribution is supported
> -	BIOS Revision: 1.0
> +		UEFI is supported
> +		System is a virtual machine
> +	BIOS Revision: 0.1

Of course, this is not to say that SeaBIOS and OVMF should continue
patching the Type 0 table field-wise. If we can control the Table 0
fields on this level of detail on the qemu command line, and the parent
of qemu (libvirtd or the user's shell) takes care to set them in
accordance with the guest firmware, then the full blob suffices for
Table 0 too.

(I'm retaining the rest of the diff below.)

Thanks
Laszlo

>
> -Handle 0x0100, DMI type 1, 27 bytes
> +Handle 0x0001, DMI type 1, 27 bytes
>  System Information
>  	Manufacturer: Red Hat
>  	Product Name: KVM
>  	Version: RHEL 7.0.0 PC (i440FX + PIIX, 1996)
> -	Serial Number: Not Specified
> -	UUID: C0F384E5-6AEA-46E9-8340-E5AF2F0DCC9B
> +	Serial Number: n/a
> +	UUID: 8A2A6D47-99A6-486D-AFAE-A53741464C37
>  	Wake-up Type: Power Switch
> -	SKU Number: Not Specified
> +	SKU Number: n/a
>  	Family: Red Hat Enterprise Linux
>
> -Handle 0x0300, DMI type 3, 20 bytes
> -Chassis Information
> -	Manufacturer: Bochs
> -	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
> -
> -Handle 0x0401, DMI type 4, 32 bytes
> -Processor Information
> -	Socket Designation: CPU 1
> -	Type: Central Processor
> -	Family: Other
> -	Manufacturer: Bochs
> -	ID: 63 06 00 00 FD FB 8B 07
> -	Version: Not Specified
> -	Voltage: Unknown
> -	External Clock: Unknown
> -	Max Speed: 2000 MHz
> -	Current Speed: 2000 MHz
> -	Status: Populated, Enabled
> -	Upgrade: Other
> -	L1 Cache Handle: Not Provided
> -	L2 Cache Handle: Not Provided
> -	L3 Cache Handle: Not Provided
> -
> -Handle 0x0402, DMI type 4, 32 bytes
> -Processor Information
> -	Socket Designation: CPU 2
> -	Type: Central Processor
> -	Family: Other
> -	Manufacturer: Bochs
> -	ID: 63 06 00 00 FD FB 8B 07
> -	Version: Not Specified
> -	Voltage: Unknown
> -	External Clock: Unknown
> -	Max Speed: 2000 MHz
> -	Current Speed: 2000 MHz
> -	Status: Populated, Enabled
> -	Upgrade: Other
> -	L1 Cache Handle: Not Provided
> -	L2 Cache Handle: Not Provided
> -	L3 Cache Handle: Not Provided
> -
> -Handle 0x1000, DMI type 16, 15 bytes
> -Physical Memory Array
> -	Location: Other
> -	Use: System Memory
> -	Error Correction Type: Multi-bit ECC
> -	Maximum Capacity: 1 GB
> -	Error Information Handle: Not Provided
> -	Number Of Devices: 1
> -
> -Handle 0x1100, DMI type 17, 21 bytes
> -Memory Device
> -	Array Handle: 0x1000
> -	Error Information Handle: 0x0000
> -	Total Width: 64 bits
> -	Data Width: 64 bits
> -	Size: 1024 MB
> -	Form Factor: DIMM
> -	Set: None
> -	Locator: DIMM 0
> -	Bank Locator: Not Specified
> -	Type: RAM
> -	Type Detail: None
> -
> -Handle 0x1300, DMI type 19, 15 bytes
> -Memory Array Mapped Address
> -	Starting Address: 0x00000000000
> -	Ending Address: 0x0003FFFFFFF
> -	Range Size: 1 GB
> -	Physical Array Handle: 0x1000
> -	Partition Width: 1
> -
> -Handle 0x1400, DMI type 20, 19 bytes
> -Memory Device Mapped Address
> -	Starting Address: 0x00000000000
> -	Ending Address: 0x0003FFFFFFF
> -	Range Size: 1 GB
> -	Physical Device Handle: 0x1100
> -	Memory Array Mapped Address Handle: 0x1300
> -	Partition Row Position: 1
> -
> -Handle 0x2000, DMI type 32, 11 bytes
> -System Boot Information
> -	Status: No errors detected
> -
> -Handle 0x7F00, DMI type 127, 4 bytes
> +Handle 0xFEFF, DMI type 127, 4 bytes
>  End Of Table
>