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

[Corey Minyard <tcminyard@gmail.com>]

On 07/30/2012 12:25 PM, Anthony Liguori wrote:
> Corey Minyard <cminyard@mvista.com> writes:
>
>> On 07/30/2012 10:37 AM, Anthony Liguori wrote:
>>> minyard@acm.org writes:
>>>
>>>> From: Corey Minyard <cminyard@mvista.com>
>>>>
>>>> There was no way to directly add a table entry to the SMBIOS table,
>>>> even though the BIOS supports this.  So add a function to do this.
>>>> This is in preparation for the IPMI handler adding it's SMBIOS table
>>>> entry.
>>>>
>>>> Signed-off-by: Corey Minyard <cminyard@mvista.com>
>>> I don't expect that hardware ever adds SMBIOS entries.  Rather, the BIOS
>>> adds the entries by probing the hardware.
>> Well, memory entries are added by QEMU, why not let the BIOS probe for
>> that?
> QEMU doesn't add any entries by default.  SeaBIOS owns SMBIOS.  QEMU
> uses a backchannel to hand SeaBIOS tables that SeaBIOS can then expose.
> The reason we use a table based interface is because type 0 and type 1
> tables can have vendor extensions that are in a vendor specific format.
>
> But SeaBIOS unquestionably owns SMBIOS generation.
>
>>   Plus, I really doubt that BIOSes on real systems probe for this.
>> I'd guess they are hard-coded.
> I think you'd be surprised how little is hard coded on modern BIOSes.
>
>>> So I think you should solve this in SeaBIOS, instead of trying to do it
>>> in QEMU.  I think that also solves the problem you have with
>>> pre-firmware init.
>> The user can pass the I/O base and IRQ values in on the QEMU command
>> line, and they can be arbitrary values.  The BIOS is not going to be
>> able to probe for those.
> Then pass the information that the BIOS needs through fw_cfg.  That's
> what it's there for.

Ok, I understand.  Thanks, I'll look at doing it this way.

-corey