[Qemu-devel] [PATCH] ppc/pnv: restrict BMC object to the BMC simulator

[Qemu-devel] [PATCH] ppc/pnv: restrict BMC object to the BMC simulator

[Cédric Le Goater]

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 <clg@kaod.org>
---

 Corey,

 Should we externalize the TYPE_IPMI_BMC_EXTERN and TYPE_IPMI_BMC_SIMULATOR
 defines ? 

 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);
     }

Re: [Qemu-devel] [PATCH] ppc/pnv: restrict BMC object to the BMC simulator

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]

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 <clg@kaod.org>

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]