qemu-devel
[Top][All Lists]
Advanced

[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
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]