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

[Corey Minyard <minyard@acm.org>]

On Tue, Sep 29, 2020 at 06:05:16PM -0700, Havard Skinnemoen wrote:
> 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?

This might be argument for keeping them in separate qemu processes.  But
it would be really cool if you could start up a single qemu and have a
BMC built-in running it's own code.  I'm sure something could be done to
simulate a power off.  If you can stop the CPUs, that's probably good
enough.

-corey

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