Re: [RFC 0/3] QEMU as IPMI BMC emulator

[Havard Skinnemoen]

On Mon, Sep 28, 2020 at 10:27 PM Cédric Le Goater <clg@kaod.org> wrote:
>
> 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

Oh, cool, if we split that into an Aspeed part and a VM protocol part,
it's basically what I had in mind. Are you planning to submit that, or
would it be OK if we base our work on it?

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

Right. Perhaps the next step should be an out-of-process flash protocol?

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

Cool.

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

Interesting. Will it be too slow to run the server and BMC in separate
processes?

We might actually be more interested in going the other way and move
more things out of process, as we start to tackle larger, more complex
systems.

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

It sounds great to have the option to simulate multiple architectures
in the same process, and getting rid of single-arch assumptions seems
like a nice cleanup. However, I'm hoping we'll still support
multi-process system emulation (and the MultiProcessQEMU work seems to
be moving in that direction as well).

> Anyhow, the IPMI documentation you provided is good to have.

If you like, I can split off patch 1-2 (or just 2) and post them
separately while we work on the BMC-side device emulation. If we
decide to keep patch 1 and the block diagrams, we probably need to do
something better for the font path.

Thanks,

Havard