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

[Corey Minyard]

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.

I also don't know if people will be wanting this on other 
architectures.  IPMI is certainly available on ia64.  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.

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

IMHO, we should either have a single IPMI interface type at a fixed 
location with a fixed interrupt, or we should make it flexible. 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