[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC 0/3] QEMU as IPMI BMC emulator
From: |
Cédric Le Goater |
Subject: |
Re: [RFC 0/3] QEMU as IPMI BMC emulator |
Date: |
Tue, 29 Sep 2020 07:27:08 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 |
On 9/29/20 2:39 AM, Havard Skinnemoen wrote:
> This series briefly documents the existing IPMI device support for main
> processor emulation, and goes on to propose a similar device structure to
> emulate IPMI responder devices in BMC machines. This would allow a qemu
> instance running BMC firmware to serve as an external BMC for a qemu instance
> running server software.
Great idea !
I started working on this topic some years ago with the QEMU PowerNV machine
and the Aspeed machine. They can communicate over network with this iBT device
patch :
https://github.com/legoater/qemu/commit/3677ee52f75065b0f65f36382a62f080ac74d683
This is good enough for the IPMI needs of OpenPOWER systems but the overall
system lacks a few bus. An important one being the LPC bus which we use for
PNOR mappings.
So, we added a little PNOR device in the QEMU PowerNV machine and mapped
its contents in the FW address space of the LPC bus. With the internal IPMI
BMC simulator, it mimics well enough an OpenPOWER system from the host
perspective.
All this to say, that if the goal is full system emulation, we should may
be take another approach and work on the QEMU internals to run multiple
architectures in the same QEMU binary.
According to Peter, this is mostly a configure/build issue and cleanups
are needed to remove the assumptions that were done with single arch
binaries. A big task but not necessarily difficult. I will help for
ARM and PPC !
Anyhow, the IPMI documentation you provided is good to have.
Thanks,
C.
> RFC only at this point because the series does not include actual code to
> implement this. I'd appreciate some initial feedback on
>
> 1. Whether anyone else is interested in something like this.
> 2. Completeness (i.e. anything that could be explained in more detail in the
> docs).
> 3. Naming, and whether 'specs' is the right place to put this.
> 4. Whether it's OK to enable the blockdiag sphinx extension (if not, I'll just
> toss the block diagrams and turn the docs into walls of text).
>
> If this seems reasonable, I'll start working with one of my team mates on
> implementing the common part, as well as the Nuvoton-specific responder
> device.
> Possibly also an Aspeed device.
>
> Havard Skinnemoen (3):
> docs: enable sphinx blockdiag extension
> docs/specs: IPMI device emulation: main processor
> docs/specs: IPMI device emulation: BMC
>
> docs/conf.py | 5 +-
> docs/specs/index.rst | 1 +
> docs/specs/ipmi.rst | 183 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 188 insertions(+), 1 deletion(-)
> create mode 100644 docs/specs/ipmi.rst
>
- [RFC 0/3] QEMU as IPMI BMC emulator, Havard Skinnemoen, 2020/09/28
- [RFC 1/3] docs: enable sphinx blockdiag extension, Havard Skinnemoen, 2020/09/28
- [RFC 2/3] docs/specs: IPMI device emulation: main processor, Havard Skinnemoen, 2020/09/28
- [RFC 3/3] docs/specs: IPMI device emulation: BMC, Havard Skinnemoen, 2020/09/28
- Re: [RFC 0/3] QEMU as IPMI BMC emulator, no-reply, 2020/09/28
- Re: [RFC 0/3] QEMU as IPMI BMC emulator, no-reply, 2020/09/28
- Re: [RFC 0/3] QEMU as IPMI BMC emulator,
Cédric Le Goater <=
- Re: [RFC 0/3] QEMU as IPMI BMC emulator, Corey Minyard, 2020/09/29