On Fri, Apr 28, 2017 at 10:26:31AM +0200, Cédric Le Goater wrote: > Today, when a PowerNV guest runs, it uses the sensor definitions of > the BMC simulator to populate the device tree. But an external IPMI > BMC could also be used and, in that case, it is not (yet) possible to > retrieve the sensor list. Generating the OEM SEL event for shutdown or > reboot also does not make sense as it should be generated on the BMC > side. > > This change allows a guest to use an 'ipmi-bmc-extern' backend to the > 'isa-ipmi-bt' device and a 'chardev' for transport such as : > > -chardev socket,id=ipmi0,host=localhost,port=9002,reconnect=10 \ > -device ipmi-bmc-extern,id=bmc0,chardev=ipmi0 \ > -device isa-ipmi-bt,bmc=bmc0,irq=10 > > and connect to a BMC simulator, the OpenIPMI ipmi_sim simulator for > instance. > > Signed-off-by: Cédric Le Goater <[email protected]>
Applied to ppc-for-2.10.
> ---
>
> Corey,
>
> Should we externalize the TYPE_IPMI_BMC_EXTERN and TYPE_IPMI_BMC_SIMULATOR
> defines ?
That's a good question, though. My inclination would be yes.
>
> hw/ppc/pnv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: qemu-powernv-2.10.git/hw/ppc/pnv.c
> ===================================================================
> --- qemu-powernv-2.10.git.orig/hw/ppc/pnv.c
> +++ qemu-powernv-2.10.git/hw/ppc/pnv.c
> @@ -520,7 +520,7 @@ static void ppc_powernv_reset(void)
> * This is the internal simulator but it could also be an external
> * BMC.
> */
> - obj = object_resolve_path_type("", TYPE_IPMI_BMC, NULL);
> + obj = object_resolve_path_type("", "ipmi-bmc-sim", NULL);
> if (obj) {
> pnv->bmc = IPMI_BMC(obj);
> }
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
