[Skiboot] [RFC PATCH] plat/qemu: Add BT device

[Cédric Le Goater]

On 01/12/2016 04:52 AM, Stewart Smith wrote:
> Cédric Le Goater <clg at fr.ibm.com> writes:
> 
>> On 01/11/2016 11:11 AM, Benjamin Herrenschmidt wrote:
>>> On Mon, 2016-01-11 at 10:50 +0100, Cédric Le Goater wrote:
>>>> Well, the current BT device in qemu can be configured on the command 
>>>> line, it also has a configurable irq number :
>>>>
>>>>         -device ipmi-bmc-sim,id=bmc0 -device isa-ipmi-
>>>> bt,bmc=bmc0,irq=10
>>>>
>>>> So, it seems safer to let qemu populate the device tree depending 
>>>> on its qom-tree than allow skiboot to hardcode non existing devices.
>>>
>>> We could also have the powernv platform instanciate BT by default.
> 
> +1

Well, we will need to find a way to "lazy bind" the BMC object (simulator 
or external) and the IPMI interface object (isa-ipmi-bt in our case).
Currently, these are tightly coupled and you can not define the first on 
the command line and the second in the MachineClass ->init ops. That will 
crash qemu.
 
Using the ->reset ops to work around this issue is a solution but it will 
not be welcomed by maintainers. They consider this method hideous.

C.


>> yes. I gave it a try last year and add a hard time to dissociate the BT 
>> device from the backend, that can be the simulator or an external BMC. 
>> I will spend some more energy to figure out why the QOM layer was 
>> complaining.
> 
> External BMC emulator (i.e. different QEMU process) is certainly
> something we'd want to do - and that'd help the openbmc folks.
> 
>>
>> Do we have plans for a FSP simulator ? Anyhow a hardcoded BT should not 
>> be a major obstacle.
> 
> I certainly have no plans for an FSP simulator.... and I'm not sure it
> would be worth the effort, that protocol is kind of a bit crazy on our
> side, let alone what we'd have to implement to emulate FSP side of it...
> 
> Is there a simple/sane way to have a device there by default but be able
> to be disabled if one is so inclined?