On Tue, Sep 29, 2020 at 10:46 AM Corey Minyard <miny...@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 > > > >