From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwlKr-0007Ze-IL for qemu-devel@nongnu.org; Wed, 01 Aug 2012 22:40:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwlKo-000704-U5 for qemu-devel@nongnu.org; Wed, 01 Aug 2012 22:40:25 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:45770) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwlKo-0006zy-PE for qemu-devel@nongnu.org; Wed, 01 Aug 2012 22:40:22 -0400 Received: by obbta14 with SMTP id ta14so12402258obb.4 for ; Wed, 01 Aug 2012 19:40:22 -0700 (PDT) From: Anthony Liguori In-Reply-To: <5019E1D5.3010505@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> <87sjc917r7.fsf@codemonkey.ws> <20120802011543.GA12333@morn.localdomain> <5019E1D5.3010505@mvista.com> Date: Wed, 01 Aug 2012 21:40:19 -0500 Message-ID: <87sjc6nhik.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 , Kevin O'Connor Cc: qemu-devel@nongnu.org, minyard@acm.org Corey Minyard 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