Corey Minyard <cminy...@mvista.com> writes: > On 07/30/2012 10:37 AM, Anthony Liguori wrote: >> miny...@acm.org writes: >> >>> From: Corey Minyard <cminy...@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 <cminy...@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. Regards, Anthony Liguoi > > -corey
