From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49043) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sx2aC-0006vm-EY for qemu-devel@nongnu.org; Thu, 02 Aug 2012 17:05:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sx2a8-00040h-0L for qemu-devel@nongnu.org; Thu, 02 Aug 2012 17:05:24 -0400 Received: from mail-qa0-f52.google.com ([209.85.216.52]:61015) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sx2a7-00040V-Rf for qemu-devel@nongnu.org; Thu, 02 Aug 2012 17:05:19 -0400 Received: by qabj34 with SMTP id j34so1508502qab.4 for ; Thu, 02 Aug 2012 14:05:19 -0700 (PDT) From: Anthony Liguori In-Reply-To: <501AD303.2030203@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> <87sjc6nhik.fsf@codemonkey.ws> <501A6FD3.2020009@acm.org> <87sjc5i1q4.fsf@codemonkey.ws> <501AD303.2030203@mvista.com> Date: Thu, 02 Aug 2012 16:05:14 -0500 Message-ID: <87lihxatth.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: Kevin O'Connor , qemu-devel@nongnu.org, minyard@acm.org Corey Minyard writes: > On 08/02/2012 01:32 PM, Anthony Liguori wrote: >> Corey Minyard writes: >> >>> On 08/01/2012 09:40 PM, Anthony Liguori wrote: >>>> Corey Minyard writes: >>>> >>>>> On 08/01/2012 08:15 PM, Kevin O'Connor wrote: >>>>> 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. >>> That's a good question At least the interrupt is important for the user >>> to be able to specify. The specific interface type may also be >>> important if the user is trying to accomplish some specific emulation. >> Why is it important to specify the interrupt? Is this important for a >> typical user, or important for the IPMI maintainer who needs to test a >> bunch of different scenarios? :-) > > I'm not too worried about the IPMI maintainer, he can hack in what he > likes :). > > I would be worried about conflicts on interrupts with other devices. I > really don't know how people use qemu out in the wild, though. If they > are trying to get close to some specific machine, or if nobody really > cares about stuff like that. It's an LPC device? Ther aren't going to be many of those device types that would be user controllable (basically TPM and IPMI) so I don't think interrupt conflicts are a real likely issue. > I also don't know if people will be wanting this on other > architectures. IPMI is certainly available on ia64. I doubt QEMU will ever support ia64 since noone seems to care about it anymore. > In fact it's quite > common there. I've seen it on practically everything else, though it's > not so common. It's in the PPC device trees for sure, and in some uboot > device trees on other arches. Right, but this is specifically about SMBIOS/ACPI support which won't be on other architectures. > >> If it's the later, we can probably express the interrupt number as a >> #define in SeaBIOS, but still make it configurable in QEMU. Then you >> could build multiple copies of SeaBIOS and then just point QEMU at the >> right version. > > That philosophy sounds like a recipe for version overload. I'd prefer > to avoid that. > >> >>> Two other standard emulations exist, too, one in memory and one over >>> I2C. I'd eventually like to add those, if for nothing else my ability >>> to test the interfaces. >> Right, see above. It may be easier to just build multiple copies of the >> BIOS then to try and make this all dynamic. > In my experience, if you need the flexibility and don't make it dynamic, > you make things harder in the long run. But adding unnecessary > flexibility is extra work without value. Exactly. > IMHO, we should either have a single IPMI interface type at a fixed > location with a fixed interrupt, or we should make it flexible. I think fixed interrupt is what makes the most sense now. If there's a pressing need in the future to do otherwise, we can revisit. Regards, Anthony Liguori > Even if > we make it fixed, the BIOS will have to be told if the device is present > and will have to dynamically chose to add the SMBIOS table and ACPI name > space entries. > > Thanks, > > -corey > >> Regards, >> >> Anthony Liguori >> >>> If the user is trying to emulate some specific machine, setting the >>> address is also important, and I need to add the ability to specify >>> register spacing and the address space. This will become more important >>> for non-x86 machines. >>> >>> -corey >>> >>>> Regards, >>>> >>>> Anthony Liguori >>>> >>>>> -corey