qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 01/18] smbios: Add a function to directly add an


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 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]