From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyPNt-0003de-0v for qemu-devel@nongnu.org; Mon, 06 Aug 2012 11:38:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SyPNn-0002Tv-ST for qemu-devel@nongnu.org; Mon, 06 Aug 2012 11:38:20 -0400 Received: from mail-gg0-f173.google.com ([209.85.161.173]:53610) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyPNn-0002Th-N3 for qemu-devel@nongnu.org; Mon, 06 Aug 2012 11:38:15 -0400 Received: by ggnp1 with SMTP id p1so2546063ggn.4 for ; Mon, 06 Aug 2012 08:38:14 -0700 (PDT) Message-ID: <501FE4E3.6020704@acm.org> Date: Mon, 06 Aug 2012 10:38:11 -0500 From: Corey Minyard MIME-Version: 1.0 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> <87lihxatth.fsf@codemonkey.ws> In-Reply-To: <87lihxatth.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 01/18] smbios: Add a function to directly add an entry Reply-To: minyard@acm.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Corey Minyard , Kevin O'Connor , qemu-devel@nongnu.org On 08/02/2012 04:05 PM, Anthony Liguori wrote: > 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. > The implementation depends. But for SMBIOS concerns, you are probably correct. > Right, but this is specifically about SMBIOS/ACPI support which won't be > on other architectures. No, it's not. This is about passing information to the firmware. At least PPC and SPARC use the same mechanisms. > >>> 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. I wanted to think about this a bit, and in my mind if you have to pass anything, you might as well pass everything. It's not that big a difference. Since you are going to have to pass something along, the difference between passing a flag saying "IPMI is available" and passing a structure with the information doesn't seem to be that much. The main difference is the firmware is going to pull the data out of a passed in structure verses setting it to fixed values. Passing the structure gives the user the ability to specify anything and have it just work. Thanks, -corey > > 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