[Top][All Lists]
[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: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] [PATCH 01/18] smbios: Add a function to directly add an entry |
Date: |
Thu, 02 Aug 2012 16:05:14 -0500 |
User-agent: |
Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) |
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.
> I also don't know if people will be wanting this on other
> architectures. IPMI is certainly available on ia64.
I doubt QEMU will ever support ia64 since noone seems to care about it anymore.
> 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.
Right, but this is specifically about SMBIOS/ACPI support which won't be
on other architectures.
>
>> 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.
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