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

[Havard Skinnemoen]

On Tue, Sep 29, 2020 at 10:46 AM Corey Minyard <minyard@acm.org> wrote:
>
> On Mon, Sep 28, 2020 at 05:39:13PM -0700, Havard Skinnemoen via 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.
> >
> > 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.
>
> Though I've had this idea once or twice, I'm not working on real BMCs,
> so I didn't really pursue anything.  It's a good idea, I think, for the
> BMC developers, and possibly for system developers trying to do
> integration testing between BMCs and system software.
>
> You will need to tie in to more emulation than just the BMC side of the
> system interface registers.  You will also need to tie into GPIOs or
> whatnot for things like host reset.

That is true. The OpenIPMI protocol seems to handle at least some of
that, so it should be just a matter of adding a few GPIO inputs
(power, reset, ATTN, ...) to the ipmi-host-extern device.

I should add some more details about this to the doc.

> Power handling is going to be a bit weird.  The OpenIPMI emulator
> starts/stops qemu based upon power control.  It might be possible to do
> the same thing in this sort of emulator.

Hmm, yeah, I guess we can't kill/restart qemu from within qemu itself.
But perhaps stopping all CPUs and doing a full system reset might be a
good enough approximation for power-off?

> You may need extensions to the protocol, and that's fine.  I can't think
> of any at the moment, but you never know.

True.

> > 2. Completeness (i.e. anything that could be explained in more detail in the
> >    docs).
>
> It's certainly a good start.  The second patch would be useful right
> now.  There are more details, of course, but I think that's covered in
> the man page under the various devices.

Thanks, I might send the second patch separately in the next round.

Havard

> Thanks,
>
> -corey
>
> > 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
> >
> > --
> > 2.28.0.709.gb0816b6eb0-goog
> >
> >