Corey Minyard <address@hidden> writes:
On 07/30/2012 10:37 AM, Anthony Liguori wrote:
address@hidden writes:
From: Corey Minyard <address@hidden>
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 <address@hidden>
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.