Re: [Qemu-devel] [PATCH 01/18] smbios: Add a function to directly add an entry

[Anthony Liguori <anthony@codemonkey.ws>]

Corey Minyard <cminyard@mvista.com> writes:

> On 08/01/2012 08:15 PM, Kevin O'Connor wrote:
>>
>> This approach, unfortunately, leads to extra code and "double
>> handling" of infomation.
>>
>> The ultimate consumer of the data wants a binary struct which looks
>> like:
>>
>> struct smbios_type_38 {
>>      struct smbios_structure_header header;
>>      u8 interface_type;
>>      u8 ipmi_version;
>>      u8 i2c_slave_addr;
>>      u8 nv_storage_dev_addr;
>>      u64 base_addr;
>>      u8 base_addr_mod_and_irq_info;
>>      u8 interrupt_number;
>> };
>>
>> The proposed solution is to put the info in a binary struct which
>> looks like:
>>
>> struct ipmi_info {
>>      u8 str_version;
>>      u8 interface;
>>      u8 reg_space;
>>      u8 reg_spacing;
>>      u8 slave_addr;
>>      u8 irq;
>>      u8 version;
>>      u8 reserved1;
>>      u64 base_addr;
>> } PACKED;
>>
>> and then have SeaBIOS translate the latter binary struct into the
>> former.  However, there's no compelling reason to introduce a new
>> binary struct instead of using the industry standard binary struct.
>>
>> I'd prefer QEMU to just pass the SMBIOS struct and let SeaBIOS pass it
>> through to the OS.  I also think the existing fw_cfg mechanism for
>> passing SMBIOS tables should be used.  I understand that this causes
>> some contortions due to the current SMBIOS fw_cfg impementation in
>> QEMU, but it seems wrong to introduce a new fw_cfg port that
>> accomplishes the same goal as an existing fw_cfg port.
>
> Well, I should also probably add the ACPI name space definition for this 
> information, too, and the SMBIOS information is not capable of passing 
> all the information required for this (though the above structure can).
>
> I've been studying this, but I don't see an obvious way to dynamically 
> add something to the ACPI name space.  At least an easy way.

Okay, I was actually going to ask if there was an ACPI table for this.

Maybe this argues in favor of doing a fw_cfg interface?

Another question--is it really necessary for all of this to be user
specified?  Can't we just use a static SMBIOS/ACPI entry?  Then SeaBIOS
only needs to be concerned with whether or not an IPMI device exists.

Regards,

Anthony Liguori

>
> -corey