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

[Corey Minyard <tcminyard@gmail.com>]

On 08/02/2012 04:05 PM, Anthony Liguori wrote:
> Corey Minyard <cminyard@mvista.com> writes:
>
>> On 08/02/2012 01:32 PM, Anthony Liguori wrote:
>>> Corey Minyard <tcminyard@gmail.com> writes:
>>>
>>>> On 08/01/2012 09:40 PM, Anthony Liguori wrote:
>>>>> Corey Minyard <cminyard@mvista.com> 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