Corey Minyard <cminy...@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
