On Tue, Sep 29, 2020 at 06:05:16PM -0700, Havard Skinnemoen wrote: > On Tue, Sep 29, 2020 at 10:46 AM Corey Minyard <[email protected]> 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 > > > > > >
