qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: Havard Skinnemoen <hskinnemoen@google.com>
Cc: Avi.Fishman@nuvoton.com, venture@google.com,
	qemu-devel@nongnu.org, wuhaotsh@google.com, kfting@nuvoton.com,
	clg@kaod.org, joel@jms.id.au
Subject: Re: [RFC 0/3] QEMU as IPMI BMC emulator
Date: Tue, 29 Sep 2020 12:46:44 -0500	[thread overview]
Message-ID: <20200929174644.GW3674@minyard.net> (raw)
In-Reply-To: <20200929003916.4183696-1-hskinnemoen@google.com>

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.

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.

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

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

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


  parent reply	other threads:[~2020-09-29 17:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-29  0:39 [RFC 0/3] QEMU as IPMI BMC emulator Havard Skinnemoen via
2020-09-29  0:39 ` [RFC 1/3] docs: enable sphinx blockdiag extension Havard Skinnemoen via
2020-09-29  0:39 ` [RFC 2/3] docs/specs: IPMI device emulation: main processor Havard Skinnemoen via
2020-09-29  0:39 ` [RFC 3/3] docs/specs: IPMI device emulation: BMC Havard Skinnemoen via
2020-09-29  2:48 ` [RFC 0/3] QEMU as IPMI BMC emulator no-reply
2020-09-29  2:51 ` no-reply
2020-09-29  5:27 ` Cédric Le Goater
2020-09-29 16:28   ` Havard Skinnemoen
2020-10-01 15:28     ` Cédric Le Goater
2020-09-29 17:46 ` Corey Minyard [this message]
2020-09-30  1:05   ` Havard Skinnemoen
2020-09-30  1:54     ` Corey Minyard
2020-10-01 15:32     ` Cédric Le Goater

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200929174644.GW3674@minyard.net \
    --to=minyard@acm.org \
    --cc=Avi.Fishman@nuvoton.com \
    --cc=clg@kaod.org \
    --cc=hskinnemoen@google.com \
    --cc=joel@jms.id.au \
    --cc=kfting@nuvoton.com \
    --cc=qemu-devel@nongnu.org \
    --cc=venture@google.com \
    --cc=wuhaotsh@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).