| Message ID | 1493367991-21269-1-git-send-email-clg@kaod.org |
|---|---|
| State | New |
| Headers | show |
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); > } >
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); }
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(-)