From: Paolo Bonzini <pbonzini@redhat.com>
To: minyard@acm.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 00/16] Add an IPMI device to qemu
Date: Mon, 15 Dec 2014 22:21:53 +0100 [thread overview]
Message-ID: <548F50F1.4070505@redhat.com> (raw)
In-Reply-To: <1418411751-3614-1-git-send-email-minyard@acm.org>
On 12/12/2014 20:15, minyard@acm.org wrote:
> This set of patches adds an IPMI device to qemu. This is good for
> systems that require an IPMI device to work correctly, for simulating
> scenarios that require IPMI and testing software that uses IPMI, and
> of course, for the Linux IPMI driver maintainer to use to reproduce
> issues that could not be easily reproduced otherwise :).
>
> For those that don't know, IPMI is a standard for doing sensor
> monitoring and basic machine maintenance. It has local interfaces
> on the host system (four different types, SMIC, KCS, BT, and SSIF)
> that can be in I/O space, memory space, and PCI space, and in the
> case of SSIF, is on an I2C bus. It can also have network interfaces
> for out of band maintenance, though that's not directly relevant
> here. It is a message-based interface; all IPMI operations are
> done by sending command messages, results come back as response
> messages.
>
> The maintenance actions are done by a small controller on the system
> called a Baseboard Management Controller (BMC). These devices are
> always on when the system is plugged in, even if the system is off.
>
> The first 9 patches add the device itself on an ISA interface. This
> adds a KCS device and a BT device (two of the four standard IPMI
> interfaces). It also adds software to have a small BMC simulated
> inside of QEMU, and a way to connected to an external BMC (like
> openipmi library's lanserv) over the network. Those patches should
> be pretty straightforward, though I'm still not 100% sure about
> migration.
Indeed patches 1-8 should be pretty much done. And 9 looks like it's in
good shape too, though I have not reviewed it carefully enough.
I haven't checked that the patches pass checkpatch.pl; also the
preferred style over this:
+ (IPMI_INTERFACE_GET_CLASS(s))->handle_if_event(s);
is to have a function:
ipmi_interface_handle_if_event(s);
that is written like
void ipmi_interface_handle_if_event(IPMIInterface *s)
{
IPMIInterfaceClass *sc = IPMI_INTERFACE_GET_CLASS(s);
sc->handle_if_event(s);
}
Also, a function like ipmi_signal would be in the .c file. There should
be no use of *_GET_CLASS outside the .c file.
For patches 10-15, there is already code in QEMU for ACPI table
generation. Right now it uses iasl, but Igor Mammedov is also working
on an API similar to yours (the duplication is unfortunate, indeed). So
it would probably be better to integrate table construction with
"regular" SSDT construction in hw/i386/acpi-build.c. ACPI tables are
already sent to the firmware after device initialization; IIUC they are
built on demand, so there should be no change required for this anymore.
SMBIOS tables are also built in QEMU now, which simplified your work a
bit. Moving the work to a machine_done_notifier is a good idea and
matches ACPI. The only thing I'd change is using a NotifierList instead
of rolling your own smbios_device_handler struct.
BTW, any reason to choose ISA over PCI or I2C (which is supported for
i386 via the ACPI SMBus controller)?
Paolo
next prev parent reply other threads:[~2014-12-15 21:22 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-12 19:15 [Qemu-devel] [PATCH 00/16] Add an IPMI device to qemu minyard
2014-12-12 19:15 ` [Qemu-devel] [PATCH 01/16] Add a base IPMI interface minyard
2014-12-12 19:15 ` [Qemu-devel] [PATCH 02/16] ipmi: Add a PC ISA type structure minyard
2014-12-12 19:15 ` [Qemu-devel] [PATCH 03/16] ipmi: Add a KCS low-level interface minyard
2014-12-12 19:15 ` [Qemu-devel] [PATCH 04/16] ipmi: Add a BT " minyard
2014-12-12 19:15 ` [Qemu-devel] [PATCH 05/16] ipmi: Add a local BMC simulation minyard
2014-12-12 19:15 ` [Qemu-devel] [PATCH 06/16] ipmi: Add an external connection simulation interface minyard
2014-12-12 19:15 ` [Qemu-devel] [PATCH 07/16] ipmi: Add tests minyard
2014-12-12 19:15 ` [Qemu-devel] [PATCH 08/16] ipmi: Add documentation minyard
2014-12-12 19:15 ` [Qemu-devel] [PATCH 09/16] ipmi: Add migration capability to the IPMI device minyard
2014-12-12 19:15 ` [Qemu-devel] [PATCH 10/16] pc: Postpone adding ACPI and SMBIOS to fw_cfg minyard
2014-12-12 19:15 ` [Qemu-devel] [PATCH 11/16] smbios: Add a function to directly add an entry minyard
2014-12-12 19:15 ` [Qemu-devel] [PATCH 12/16] ipmi: Add SMBIOS table entry minyard
2015-02-19 2:53 ` Benjamin Herrenschmidt
2014-12-12 19:15 ` [Qemu-devel] [PATCH 13/16] acpi: Add a way to extend tables minyard
2014-12-12 19:15 ` [Qemu-devel] [PATCH 14/16] acpi: Add table construction tools minyard
2014-12-12 19:15 ` [Qemu-devel] [PATCH 15/16] ipmi: Add ACPI table entries for BMCs minyard
2015-02-19 2:54 ` Benjamin Herrenschmidt
2015-02-20 3:16 ` Corey Minyard
2015-02-22 20:48 ` Benjamin Herrenschmidt
2014-12-12 19:15 ` [Qemu-devel] [PATCH 16/16] ipmi: Add a thread to better simulate a BMC minyard
2014-12-15 21:11 ` Paolo Bonzini
2014-12-15 21:33 ` Corey Minyard
2014-12-15 21:21 ` Paolo Bonzini [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-11-12 16:32 [Qemu-devel] [PATCH 00/16] Add an IPMI device to QEMU Corey Minyard
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=548F50F1.4070505@redhat.com \
--to=pbonzini@redhat.com \
--cc=minyard@acm.org \
--cc=qemu-devel@nongnu.org \
/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).