|
From: | Corey Minyard |
Subject: | Re: [Qemu-devel] [PATCH 01/18] smbios: Add a function to directly add an entry |
Date: | Mon, 06 Aug 2012 10:38:11 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 |
On 08/02/2012 04:05 PM, Anthony Liguori wrote:
Corey Minyard <address@hidden> writes:On 08/02/2012 01:32 PM, Anthony Liguori wrote:Corey Minyard <address@hidden> writes:On 08/01/2012 09:40 PM, Anthony Liguori wrote:Corey Minyard <address@hidden> 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 LiguoriEven 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, -coreyRegards, Anthony LiguoriIf 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. -coreyRegards, Anthony Liguori-corey
[Prev in Thread] | Current Thread | [Next in Thread] |