From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42004) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Svtil-0001MN-1U for qemu-devel@nongnu.org; Mon, 30 Jul 2012 13:25:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Svtia-0007Mv-Nx for qemu-devel@nongnu.org; Mon, 30 Jul 2012 13:25:30 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:50514) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Svtia-0007Mp-Hd for qemu-devel@nongnu.org; Mon, 30 Jul 2012 13:25:20 -0400 Received: by pbbro12 with SMTP id ro12so9679430pbb.4 for ; Mon, 30 Jul 2012 10:25:19 -0700 (PDT) From: Anthony Liguori In-Reply-To: <5016B9D2.2010401@mvista.com> References: <1342724013-1633-1-git-send-email-minyard@acm.org> <1342724013-1633-2-git-send-email-minyard@acm.org> <87obmxxntb.fsf@codemonkey.ws> <5016B9D2.2010401@mvista.com> Date: Mon, 30 Jul 2012 12:25:16 -0500 Message-ID: <87sjc917r7.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 01/18] smbios: Add a function to directly add an entry List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Corey Minyard Cc: qemu-devel@nongnu.org, minyard@acm.org Corey Minyard writes: > On 07/30/2012 10:37 AM, Anthony Liguori wrote: >> minyard@acm.org writes: >> >>> From: Corey Minyard >>> >>> 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 >> 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