Re: [Qemu-devel] [PATCH v4 00/17] Add an IPMI device to QEMU

["Cédric Le Goater" <clg@fr.ibm.com>]

On 11/12/2015 08:02 PM, minyard@acm.org wrote:
> This is a long delayed patch set, but I think I have things reworked
> to make Igor happy with the way ACPI and SMBIOS work.  This is more
> consistent with the way most other things work, anyway.  It did
> require adding stubs for systems without IPMI.
> 
> The first nine patches are unchanged.
> 
> The IPMI firmware configuration storage now holds the firmware information
> in a data structure and lets it be iterated.
> 
> SMBIOS and ACPI build the tables with their existing building
> functions and call out to the IPMI one (or the stub) when the time
> comes.  This required pulling some code out of smbios.c into an
> include file and making some things global, as IPMI has to be
> configurable.
> 
> The BIOS table tests were also modified since the ACPI info is
> now in the existing SSDT.
> 
> I've also added a force-off function for external BMCs; an external
> BMC needs a way to do a hard power-off of the system if the soft
> power offs fail.
> 
> Thanks all!
> 
> -corey

Hi Corey,

Adding your patchset to Ben's work on the PowerNV platform gives us 
a promising OpenPower system simulator !

I did not have to do too much to make it work. A few SENSOR_EVENT
commands are missing which Openpower systems use. I did the merge
and quick addons here :

	https://github.com/legoater/qemu/tree/powernv-ipmi

For a first try, that went extremely well. The system boots and 
the ipmi device is fully functionnal. I guess we would need to 
define a larger set of sdrs. They can be added to the bmc simulator
device probably with time.

OpenPower systems also use some specific OEM event upon reboot 
and reset when initiated from the bmc. We need will to find a way 
to fill the event buffer with such data. Nothing complex.



I was wondering how much fix up we should be doing in the firmware 
(skiboot) when running a qemu guest. I guess we should try to 
generate as much we can of the device tree in qemu depending on
the devices available ? or shall we force the qemu platform in 
skiboot to be strictly openpower oriented ? 

Thanks,

C.