Re: First shot at adding IPMI to qemu
I haven't heard anything about these patches. Any comments, good or bad? Has anyone tried these? Thanks, -corey On 07/02/2012 02:44 PM, miny...@acm.org wrote: I had asked about getting an IPMI device into qemu and received some interest, and it's useful to me, so I've done some work to add it. The following patch set has a set of patches to add an IPMI KCS device, and IPMI BT device, a built-in BMC (IPMI management controller), and a way to attach an external BMC through a chardev. There was some discussion on whether to make the BMC internal or external, but I went ahead and added both. The internal one is fairly basic and not extensible, at least without adding code. I've modified the OpenIPMI library simulator to work with the external interface to allow it to receive connections from the qemu external simulator with a fairly basic protocol. I've also added the ability for the OpenIPMI library to manage a VM to power it on, power it off, reset it, and handle an IPMI watchdog timer. So it looks quite like a real system. Instructions for using it are in the OpenIPMI release candidate I uploaded to https://sourceforge.net/projects/openipmi Since IPMI can advertise it's presence via SMBIOS, I added a way for a driver to add an SMBIOS entry. I also added a way to query a free interrupt from the ISA bus, since the interrupt is in the SMBIOS entry and nobody really cares which one is used. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
First shot at adding IPMI to qemu
I had asked about getting an IPMI device into qemu and received some interest, and it's useful to me, so I've done some work to add it. The following patch set has a set of patches to add an IPMI KCS device, and IPMI BT device, a built-in BMC (IPMI management controller), and a way to attach an external BMC through a chardev. There was some discussion on whether to make the BMC internal or external, but I went ahead and added both. The internal one is fairly basic and not extensible, at least without adding code. I've modified the OpenIPMI library simulator to work with the external interface to allow it to receive connections from the qemu external simulator with a fairly basic protocol. I've also added the ability for the OpenIPMI library to manage a VM to power it on, power it off, reset it, and handle an IPMI watchdog timer. So it looks quite like a real system. Instructions for using it are in the OpenIPMI release candidate I uploaded to https://sourceforge.net/projects/openipmi Since IPMI can advertise it's presence via SMBIOS, I added a way for a driver to add an SMBIOS entry. I also added a way to query a free interrupt from the ISA bus, since the interrupt is in the SMBIOS entry and nobody really cares which one is used. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] isa: Add a way to query for a free interrupt
From: Corey Minyard cminy...@mvista.com
This lets devices that don't care about their interrupt number, like
IPMI, just grab any unused interrupt.
Signed-off-by: Corey Minyard cminy...@mvista.com
---
hw/isa-bus.c | 13 +
hw/isa.h |2 ++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 5a43f03..f561f21 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -71,6 +71,7 @@ qemu_irq isa_get_irq(ISADevice *dev, int isairq)
if (isairq 0 || isairq 15) {
hw_error(isa irq %d invalid, isairq);
}
+isabus-irq_inuse[isairq] = 1;
return isabus-irqs[isairq];
}
@@ -82,6 +83,18 @@ void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq)
dev-nirqs++;
}
+int isa_find_free_irq(ISABus *bus)
+{
+unsigned int i;
+
+/* 0 and 1 are called for, 2 is the chain interrupt */
+for (i = 3; i ISA_NUM_IRQS; i++) {
+ if (!bus-irq_inuse[i])
+ return i;
+}
+return 0;
+}
+
static inline void isa_init_ioport(ISADevice *dev, uint16_t ioport)
{
if (dev (dev-ioport_id == 0 || ioport dev-ioport_id)) {
diff --git a/hw/isa.h b/hw/isa.h
index f7bc4b5..9447296 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -28,6 +28,7 @@ struct ISABus {
BusState qbus;
MemoryRegion *address_space_io;
qemu_irq *irqs;
+int irq_inuse[ISA_NUM_IRQS];
};
struct ISADevice {
@@ -41,6 +42,7 @@ ISABus *isa_bus_new(DeviceState *dev, MemoryRegion
*address_space_io);
void isa_bus_irqs(ISABus *bus, qemu_irq *irqs);
qemu_irq isa_get_irq(ISADevice *dev, int isairq);
void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq);
+int isa_find_free_irq(ISABus *bus);
MemoryRegion *isa_address_space(ISADevice *dev);
ISADevice *isa_create(ISABus *bus, const char *name);
ISADevice *isa_try_create(ISABus *bus, const char *name);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] IPMI: Add a PC ISA type structure
From: Corey Minyard cminy...@mvista.com
This provides the base infrastructure to tie IPMI low-level
interfaces into a PC ISA bus.
Signed-off-by: Corey Minyard cminy...@mvista.com
---
default-configs/i386-softmmu.mak |1 +
default-configs/x86_64-softmmu.mak |1 +
hw/Makefile.objs |1 +
hw/isa_ipmi.c | 138
hw/pc.c| 12 +++
hw/pc.h| 18 +
hw/smbios.h| 12 +++
7 files changed, 183 insertions(+), 0 deletions(-)
create mode 100644 hw/isa_ipmi.c
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index eb17afc..c0aff0d 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -8,6 +8,7 @@ CONFIG_VGA_CIRRUS=y
CONFIG_VMWARE_VGA=y
CONFIG_VMMOUSE=y
CONFIG_IPMI=y
+CONFIG_ISA_IPMI=y
CONFIG_SERIAL=y
CONFIG_PARALLEL=y
CONFIG_I8254=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index e4e3e4f..615e4f2 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -8,6 +8,7 @@ CONFIG_VGA_CIRRUS=y
CONFIG_VMWARE_VGA=y
CONFIG_VMMOUSE=y
CONFIG_IPMI=y
+CONFIG_ISA_IPMI=y
CONFIG_SERIAL=y
CONFIG_PARALLEL=y
CONFIG_I8254=y
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index 0d55997..8f27ffe 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -21,6 +21,7 @@ hw-obj-$(CONFIG_ESCC) += escc.o
hw-obj-$(CONFIG_EMPTY_SLOT) += empty_slot.o
hw-obj-$(CONFIG_IPMI) += ipmi.o
+hw-obj-$(CONFIG_ISA_IPMI) += isa_ipmi.o
hw-obj-$(CONFIG_SERIAL) += serial.o
hw-obj-$(CONFIG_PARALLEL) += parallel.o
diff --git a/hw/isa_ipmi.c b/hw/isa_ipmi.c
new file mode 100644
index 000..cad78b0
--- /dev/null
+++ b/hw/isa_ipmi.c
@@ -0,0 +1,138 @@
+/*
+ * QEMU ISA IPMI KCS emulation
+ *
+ * Copyright (c) 2012 Corey Minyard, MontaVista Software, LLC
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include hw.h
+#include isa.h
+#include pc.h
+#include qemu-timer.h
+#include sysemu.h
+#include smbios.h
+#include ipmi.h
+
+
+typedef struct ISAIPMIState {
+ISADevice dev;
+uint32_t type;
+uint32_t iobase;
+uint32_t isairq;
+uint8_t slave_addr;
+IPMIState state;
+} ISAIPMIState;
+
+static int ipmi_isa_initfn(ISADevice *dev)
+{
+ISAIPMIState *isa = DO_UPCAST(ISAIPMIState, dev, dev);
+struct smbios_type_38 smb38;
+
+if (isa-iobase == -1) {
+ /* If no I/O base is specified, set the defaults */
+ switch (isa-type) {
+ case IPMI_KCS:
+ isa-iobase = 0xca2;
+ break;
+ case IPMI_BT:
+ isa-iobase = 0xe4;
+ break;
+ case IPMI_SMIC:
+ isa-iobase = 0xca9;
+ break;
+ default:
+ fprintf(stderr, Unknown IPMI type: %d\n, isa-type);
+ abort();
+ }
+}
+
+isa-state.slave_addr = isa-slave_addr;
+
+qdev_set_legacy_instance_id(dev-qdev, isa-iobase, 3);
+
+ipmi_init(isa-type, isa-state);
+
+if (isa-isairq 0) {
+ isa_init_irq(dev, isa-state.irq, isa-isairq);
+ isa-state.use_irq = 1;
+}
+
+isa_register_ioport(dev, isa-state.io, isa-iobase);
+
+smb38.header.type = 38;
+smb38.header.length = sizeof(smb38);
+smb38.header.handle = 0x3000;
+smb38.interface_type = isa-state.smbios_type;
+smb38.ipmi_version = 0x20;
+smb38.i2c_slave_addr = isa-state.slave_addr;
+smb38.nv_storage_dev_addr = 0;
+
+/* or 1 to set it to I/O space */
+smb38.base_addr = isa-iobase | 1;
+
+ /* 1-byte boundaries, addr bit0=0, level triggered irq */
+smb38.base_addr_mod_and_irq_info = 1;
+smb38.interrupt_number = isa-isairq;
+smbios_table_entry_add((struct smbios_structure_header *) smb38);
+
+return 0;
+}
+
+static Property ipmi_isa_properties[] = {
+DEFINE_PROP_HEX32(type, ISAIPMIState, type, IPMI_KCS
[PATCH 9/9] IPMI: Add an external connection simulation interface
From: Corey Minyard cminy...@mvista.com
This adds an interface for IPMI that connects to a remote
BMC over a chardev (generally a TCP socket). The OpenIPMI
lanserv simulator describes this interface, see that for
interface details.
Signed-off-by: Corey Minyard cminy...@mvista.com
---
default-configs/i386-softmmu.mak |1 +
default-configs/x86_64-softmmu.mak |1 +
hw/Makefile.objs |1 +
hw/ipmi_extern.c | 421
hw/ipmi_extern.h | 75 +++
5 files changed, 499 insertions(+), 0 deletions(-)
create mode 100644 hw/ipmi_extern.c
create mode 100644 hw/ipmi_extern.h
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 8c99d5d..325f92e 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -12,6 +12,7 @@ CONFIG_ISA_IPMI=y
CONFIG_IPMI_KCS=y
CONFIG_IPMI_BT=y
CONFIG_IPMI_LOCAL=y
+CONFIG_IPMI_EXTERN=y
CONFIG_SERIAL=y
CONFIG_PARALLEL=y
CONFIG_I8254=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 4d01883..2ac9177 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -12,6 +12,7 @@ CONFIG_ISA_IPMI=y
CONFIG_IPMI_KCS=y
CONFIG_IPMI_BT=y
CONFIG_IPMI_LOCAL=y
+CONFIG_IPMI_EXTERN=y
CONFIG_SERIAL=y
CONFIG_PARALLEL=y
CONFIG_I8254=y
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index 193227d..06757b0 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -25,6 +25,7 @@ hw-obj-$(CONFIG_ISA_IPMI) += isa_ipmi.o
hw-obj-$(CONFIG_IPMI_KCS) += ipmi_kcs.o
hw-obj-$(CONFIG_IPMI_BT) += ipmi_bt.o
hw-obj-$(CONFIG_IPMI_LOCAL) += ipmi_sim.o
+hw-obj-$(CONFIG_IPMI_EXTERN) += ipmi_extern.o
hw-obj-$(CONFIG_SERIAL) += serial.o
hw-obj-$(CONFIG_PARALLEL) += parallel.o
diff --git a/hw/ipmi_extern.c b/hw/ipmi_extern.c
new file mode 100644
index 000..bbb8469
--- /dev/null
+++ b/hw/ipmi_extern.c
@@ -0,0 +1,421 @@
+/*
+ * IPMI BMC external connection
+ *
+ * Copyright (c) 2012 Corey Minyard, MontaVista Software, LLC
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/*
+ * This is designed to connect with OpenIPMI's lanserv serial interface
+ * using the VM connection type. See that for details.
+ */
+
+#include ipmi_extern.h
+
+static int can_receive(void *opaque);
+static void receive(void *opaque, const uint8_t *buf, int size);
+static void chr_event(void *opaque, int event);
+
+static unsigned char
+ipmb_checksum(const unsigned char *data, int size, unsigned char start)
+{
+ unsigned char csum = start;
+
+ for (; size 0; size--, data++)
+ csum += *data;
+
+ return csum;
+}
+
+static void continue_send(IPMIState *s, IPMIExternState *es)
+{
+if (es-outlen == 0)
+ goto check_reset;
+
+ send:
+es-outpos += qemu_chr_fe_write(es-chr, es-outbuf + es-outpos,
+ es-outlen - es-outpos);
+if (es-outpos es-outlen) {
+ /* Not fully transmitted, try again in a 10ms */
+ qemu_mod_timer(es-extern_timer,
+ qemu_get_clock_ns(vm_clock) + 1000);
+} else {
+ /* Sent */
+ es-outlen = 0;
+ es-outpos = 0;
+ if (!es-sending_cmd)
+ es-waiting_rsp = 1;
+ else
+ es-sending_cmd = 0;
+
+check_reset:
+ if (es-send_reset) {
+ /* Send the reset */
+ es-outbuf[0] = VM_CMD_RESET;
+ es-outbuf[1] = VM_CMD_CHAR;
+ es-outlen = 2;
+ es-outpos = 0;
+ es-send_reset = 0;
+ es-sending_cmd = 1;
+ goto send;
+ }
+
+ if (es-waiting_rsp)
+ /* Make sure we get a response within 4 seconds. */
+ qemu_mod_timer(es-extern_timer,
+ qemu_get_clock_ns(vm_clock) + 40ULL);
+}
+return;
+}
+
+static void extern_timeout(void *opaque)
+{
+IPMIState *s = opaque
[PATCH 1/9] smbios: Add a function to directly add an entry
From: Corey Minyard cminy...@mvista.com
There was no way to directly add a table entry to the SMBIOS table,
even though the BIOS supports this. So add a function to do this.
This is in preparation for the IPMI handler adding it's SMBIOS table
entry.
Signed-off-by: Corey Minyard cminy...@mvista.com
---
hw/smbios.c | 27 +++
hw/smbios.h | 15 ---
2 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/hw/smbios.c b/hw/smbios.c
index c57237d..98c7f99 100644
--- a/hw/smbios.c
+++ b/hw/smbios.c
@@ -178,6 +178,33 @@ static void smbios_build_type_1_fields(const char *t)
strlen(buf) + 1, buf);
}
+int smbios_table_entry_add(struct smbios_structure_header *entry)
+{
+struct smbios_table *table;
+struct smbios_structure_header *header;
+unsigned int size = entry-length;
+
+if (!smbios_entries) {
+smbios_entries_len = sizeof(uint16_t);
+smbios_entries = g_malloc0(smbios_entries_len);
+}
+smbios_entries = g_realloc(smbios_entries, smbios_entries_len +
+ sizeof(*table) + size);
+table = (struct smbios_table *)(smbios_entries + smbios_entries_len);
+table-header.type = SMBIOS_TABLE_ENTRY;
+table-header.length = cpu_to_le16(sizeof(*table) + size);
+
+header = (struct smbios_structure_header *)(table-data);
+memcpy(header, entry, size);
+
+smbios_check_collision(header-type, SMBIOS_TABLE_ENTRY);
+
+smbios_entries_len += sizeof(*table) + size;
+(*(uint16_t *)smbios_entries) =
+ cpu_to_le16(le16_to_cpu(*(uint16_t *)smbios_entries) + 1);
+return 0;
+}
+
int smbios_entry_add(const char *t)
{
char buf[1024];
diff --git a/hw/smbios.h b/hw/smbios.h
index 94e3641..6431a15 100644
--- a/hw/smbios.h
+++ b/hw/smbios.h
@@ -13,21 +13,22 @@
*
*/
+/* This goes at the beginning of every SMBIOS structure. */
+struct smbios_structure_header {
+uint8_t type;
+uint8_t length;
+uint16_t handle;
+} QEMU_PACKED;
+
int smbios_entry_add(const char *t);
void smbios_add_field(int type, int offset, int len, void *data);
uint8_t *smbios_get_table(size_t *length);
+int smbios_table_entry_add(struct smbios_structure_header *entry);
/*
* SMBIOS spec defined tables
*/
-/* This goes at the beginning of every SMBIOS structure. */
-struct smbios_structure_header {
-uint8_t type;
-uint8_t length;
-uint16_t handle;
-} QEMU_PACKED;
-
/* SMBIOS type 0 - BIOS Information */
struct smbios_type_0 {
struct smbios_structure_header header;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/9] IPMI: Add a local BMC simulation
From: Corey Minyard cminy...@mvista.com
This provides a minimal local BMC, basically enough to comply with the
spec and provide a complete watchdog timer (including a sensor, SDR,
and event).
Signed-off-by: Corey Minyard cminy...@mvista.com
---
default-configs/i386-softmmu.mak |1 +
default-configs/x86_64-softmmu.mak |1 +
hw/Makefile.objs |1 +
hw/ipmi_sim.c | 1273
hw/ipmi_sim.h | 270
5 files changed, 1546 insertions(+), 0 deletions(-)
create mode 100644 hw/ipmi_sim.c
create mode 100644 hw/ipmi_sim.h
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index f8f8e6d..8c99d5d 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -11,6 +11,7 @@ CONFIG_IPMI=y
CONFIG_ISA_IPMI=y
CONFIG_IPMI_KCS=y
CONFIG_IPMI_BT=y
+CONFIG_IPMI_LOCAL=y
CONFIG_SERIAL=y
CONFIG_PARALLEL=y
CONFIG_I8254=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 8c1177d..4d01883 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -11,6 +11,7 @@ CONFIG_IPMI=y
CONFIG_ISA_IPMI=y
CONFIG_IPMI_KCS=y
CONFIG_IPMI_BT=y
+CONFIG_IPMI_LOCAL=y
CONFIG_SERIAL=y
CONFIG_PARALLEL=y
CONFIG_I8254=y
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index e1d30cc..193227d 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -24,6 +24,7 @@ hw-obj-$(CONFIG_IPMI) += ipmi.o
hw-obj-$(CONFIG_ISA_IPMI) += isa_ipmi.o
hw-obj-$(CONFIG_IPMI_KCS) += ipmi_kcs.o
hw-obj-$(CONFIG_IPMI_BT) += ipmi_bt.o
+hw-obj-$(CONFIG_IPMI_LOCAL) += ipmi_sim.o
hw-obj-$(CONFIG_SERIAL) += serial.o
hw-obj-$(CONFIG_PARALLEL) += parallel.o
diff --git a/hw/ipmi_sim.c b/hw/ipmi_sim.c
new file mode 100644
index 000..6813a86
--- /dev/null
+++ b/hw/ipmi_sim.c
@@ -0,0 +1,1273 @@
+/*
+ * IPMI BMC emulation
+ *
+ * Copyright (c) 2012 Corey Minyard, MontaVista Software, LLC
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include stdio.h
+#include string.h
+#include ipmi_sim.h
+
+static void ipmi_sim_handle_timeout(IPMIState *s);
+
+static void ipmi_gettime(struct ipmi_time *time)
+{
+int64_t stime;
+
+stime = get_clock_realtime();
+time-tv_sec = stime / 10LL;
+time-tv_nsec = stime % 10LL;
+}
+
+static int64_t ipmi_getmonotime(void)
+{
+return qemu_get_clock_ns(vm_clock);
+}
+
+static void ipmi_timeout(void *opaque)
+{
+IPMIState *s = opaque;
+
+ipmi_sim_handle_timeout(s);
+}
+
+static void set_timestamp(IPMISimState *ss, uint8_t *ts)
+{
+unsigned int val;
+struct ipmi_time now;
+
+ipmi_gettime(now);
+val = now.tv_sec + ss-sel.time_offset;
+ts[0] = val 0xff;
+ts[1] = (val 8) 0xff;
+ts[2] = (val 16) 0xff;
+ts[3] = (val 24) 0xff;
+}
+
+static void sdr_inc_reservation(IPMISdr *sdr)
+{
+sdr-reservation++;
+if (sdr-reservation == 0)
+ sdr-reservation = 1;
+}
+
+static int sdr_add_entry(IPMISimState *ss, const uint8_t *entry,
+unsigned int len, uint16_t *recid)
+{
+if ((len 5) || (len 255))
+ return 1;
+
+if (entry[ss-sdr.next_free + 4] != len)
+ return 1;
+
+if (ss-sdr.next_free + len MAX_SDR_SIZE) {
+ ss-sdr.overflow = 1;
+ return 1;
+}
+
+memcpy(ss-sdr.sdr + ss-sdr.next_free, entry, len);
+ss-sdr.sdr[ss-sdr.next_free] = ss-sdr.next_rec_id 0xff;
+ss-sdr.sdr[ss-sdr.next_free+1] = (ss-sdr.next_rec_id 8) 0xff;
+ss-sdr.sdr[ss-sdr.next_free+2] = 0x51; /* Conform to IPMI 1.5 spec */
+
+if (recid)
+ *recid = ss-sdr.next_rec_id;
+ss-sdr.next_rec_id++;
+set_timestamp(ss, ss-sdr.last_addition);
+ss-sdr.next_free += len;
+sdr_inc_reservation(ss-sdr);
+return 0;
+}
+
+static int sdr_find_entry(IPMISdr *sdr, uint16_t recid,
+ unsigned int *retpos, uint16_t *nextrec
[PATCH 4/9] Add a base IPMI interface
From: Corey Minyard cminy...@mvista.com
Add the basic IPMI types and infrastructure to QEMU. Low-level
interfaces and simulation interfaces will register with this; it's
kind of the go-between to tie them together.
Signed-off-by: Corey Minyard cminy...@mvista.com
---
default-configs/i386-softmmu.mak |1 +
default-configs/x86_64-softmmu.mak |1 +
hw/Makefile.objs |2 +
hw/ipmi.c | 147 +++
hw/ipmi.h | 192
qemu-doc.texi |2 +
qemu-options.hx| 35 +++
sysemu.h |8 ++
vl.c | 46 +
9 files changed, 434 insertions(+), 0 deletions(-)
create mode 100644 hw/ipmi.c
create mode 100644 hw/ipmi.h
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 2c78175..eb17afc 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -7,6 +7,7 @@ CONFIG_VGA_ISA=y
CONFIG_VGA_CIRRUS=y
CONFIG_VMWARE_VGA=y
CONFIG_VMMOUSE=y
+CONFIG_IPMI=y
CONFIG_SERIAL=y
CONFIG_PARALLEL=y
CONFIG_I8254=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 233a856..e4e3e4f 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -7,6 +7,7 @@ CONFIG_VGA_ISA=y
CONFIG_VGA_CIRRUS=y
CONFIG_VMWARE_VGA=y
CONFIG_VMMOUSE=y
+CONFIG_IPMI=y
CONFIG_SERIAL=y
CONFIG_PARALLEL=y
CONFIG_I8254=y
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index 30c0b78..0d55997 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -20,6 +20,8 @@ hw-obj-$(CONFIG_M48T59) += m48t59.o
hw-obj-$(CONFIG_ESCC) += escc.o
hw-obj-$(CONFIG_EMPTY_SLOT) += empty_slot.o
+hw-obj-$(CONFIG_IPMI) += ipmi.o
+
hw-obj-$(CONFIG_SERIAL) += serial.o
hw-obj-$(CONFIG_PARALLEL) += parallel.o
hw-obj-$(CONFIG_I8254) += i8254_common.o i8254.o
diff --git a/hw/ipmi.c b/hw/ipmi.c
new file mode 100644
index 000..86a097b
--- /dev/null
+++ b/hw/ipmi.c
@@ -0,0 +1,147 @@
+/*
+ * QEMU IPMI emulation
+ *
+ * Copyright (c) 2012 Corey Minyard, MontaVista Software, LLC
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include hw.h
+#include ipmi.h
+#include sysemu.h
+#include qmp-commands.h
+
+static void (*ipmi_init_handlers[4])(IPMIState *s);
+
+void register_ipmi_type(unsigned int type, void (*init)(IPMIState *s))
+{
+ipmi_init_handlers[type] = init;
+}
+
+static void (*ipmi_sim_init_handlers[2])(IPMIState *s);
+
+void register_ipmi_sim(unsigned int iftype, void (*init)(IPMIState *s))
+{
+ipmi_sim_init_handlers[iftype] = init;
+}
+
+
+#ifdef DO_IPMI_THREAD
+static void *ipmi_thread(void *opaque)
+{
+IPMIState *s = opaque;
+int64_t wait_until;
+
+ipmi_lock();
+for (;;) {
+ qemu_cond_wait(s-waker, s-lock);
+ wait_until = 0;
+ while (s-do_wake) {
+ s-do_wake = 0;
+ s-handle_if_event(s);
+ }
+}
+ipmi_unlock();
+return NULL;
+}
+#endif
+
+static int ipmi_do_hw_op(IPMIState *s, enum ipmi_op op, int checkonly)
+{
+switch(op) {
+case IPMI_RESET_CHASSIS:
+ if (checkonly)
+ return 0;
+ qemu_system_reset_request();
+ return 0;
+
+case IPMI_POWEROFF_CHASSIS:
+ if (checkonly)
+ return 0;
+ qemu_system_powerdown_request();
+ return 0;
+
+case IPMI_SEND_NMI:
+ if (checkonly)
+ return 0;
+ qemu_mutex_lock_iothread();
+ qmp_inject_nmi(NULL);
+ qemu_mutex_unlock_iothread();
+ return 0;
+
+case IPMI_POWERCYCLE_CHASSIS:
+case IPMI_PULSE_DIAG_IRQ:
+case IPMI_SHUTDOWN_VIA_ACPI_OVERTEMP:
+case IPMI_POWERON_CHASSIS:
+default:
+ return IPMI_CC_COMMAND_NOT_SUPPORTED;
+}
+}
+
+static void ipmi_set_irq_enable(IPMIState *s, int val)
+{
+s-irqs_enabled = val;
+}
+
+static
[PATCH 7/9] IPMI: Add a BT low-level interface
From: Corey Minyard cminy...@mvista.com
This provides the simulation of the BT hardware interface for
IPMI.
Signed-off-by: Corey Minyard cminy...@mvista.com
---
default-configs/i386-softmmu.mak |1 +
default-configs/x86_64-softmmu.mak |1 +
hw/Makefile.objs |1 +
hw/ipmi_bt.c | 265
hw/ipmi_bt.h | 99 +
5 files changed, 367 insertions(+), 0 deletions(-)
create mode 100644 hw/ipmi_bt.c
create mode 100644 hw/ipmi_bt.h
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index b549389..f8f8e6d 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -10,6 +10,7 @@ CONFIG_VMMOUSE=y
CONFIG_IPMI=y
CONFIG_ISA_IPMI=y
CONFIG_IPMI_KCS=y
+CONFIG_IPMI_BT=y
CONFIG_SERIAL=y
CONFIG_PARALLEL=y
CONFIG_I8254=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index af7d2a9..8c1177d 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -10,6 +10,7 @@ CONFIG_VMMOUSE=y
CONFIG_IPMI=y
CONFIG_ISA_IPMI=y
CONFIG_IPMI_KCS=y
+CONFIG_IPMI_BT=y
CONFIG_SERIAL=y
CONFIG_PARALLEL=y
CONFIG_I8254=y
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index 99e5d1e..e1d30cc 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -23,6 +23,7 @@ hw-obj-$(CONFIG_EMPTY_SLOT) += empty_slot.o
hw-obj-$(CONFIG_IPMI) += ipmi.o
hw-obj-$(CONFIG_ISA_IPMI) += isa_ipmi.o
hw-obj-$(CONFIG_IPMI_KCS) += ipmi_kcs.o
+hw-obj-$(CONFIG_IPMI_BT) += ipmi_bt.o
hw-obj-$(CONFIG_SERIAL) += serial.o
hw-obj-$(CONFIG_PARALLEL) += parallel.o
diff --git a/hw/ipmi_bt.c b/hw/ipmi_bt.c
new file mode 100644
index 000..39f099e
--- /dev/null
+++ b/hw/ipmi_bt.c
@@ -0,0 +1,265 @@
+/*
+ * QEMU IPMI BT emulation
+ *
+ * Copyright (c) 2012 Corey Minyard, MontaVista Software, LLC
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include hw.h
+
+#include ipmi.h
+#include ipmi_bt.h
+
+#define IPMI_CMD_GET_BT_INTF_CAP 0x36
+
+static void ipmi_bt_handle_event(IPMIState *s)
+{
+IPMIBtState *bt = s-typeinfo;
+
+ipmi_lock();
+if (s-inlen 4)
+ goto out;
+/* Note that overruns are handled by handle_command */
+if (s-inmsg[0] != (s-inlen - 1)) {
+ /* Length mismatch, just ignore. */
+ IPMI_BT_SET_BBUSY(bt-control_reg, 1);
+ s-inlen = 0;
+ goto out;
+}
+if ((s-inmsg[1] == (IPMI_NETFN_APP 2))
+ (s-inmsg[3] == IPMI_CMD_GET_BT_INTF_CAP)) {
+ /* We handle this one ourselves. */
+ s-outmsg[0] = 9;
+ s-outmsg[1] = s-inmsg[1] | 0x04;
+ s-outmsg[2] = s-inmsg[2];
+ s-outmsg[3] = s-inmsg[3];
+ s-outmsg[4] = 0;
+ s-outmsg[5] = 1; /* Only support 1 outstanding request. */
+ if (sizeof(s-inmsg) 0xff) /* Input buffer size */
+ s-outmsg[6] = 0xff;
+ else
+ s-outmsg[6] = (unsigned char ) sizeof(s-inmsg);
+ if (sizeof(s-outmsg) 0xff) /* Output buffer size */
+ s-outmsg[7] = 0xff;
+ else
+ s-outmsg[7] = (unsigned char) sizeof(s-outmsg);
+ s-outmsg[8] = 10; /* Max request to response time */
+ s-outmsg[9] = 0; /* Don't recommend retries */
+ s-outlen = 10;
+ IPMI_BT_SET_BBUSY(bt-control_reg, 0);
+ IPMI_BT_SET_B2H_ATN(bt-control_reg, 1);
+ if (s-use_irq s-irqs_enabled
+ !IPMI_BT_GET_B2H_IRQ(bt-mask_reg)
+ IPMI_BT_GET_B2H_IRQ_EN(bt-mask_reg)) {
+ IPMI_BT_SET_B2H_IRQ(bt-mask_reg, 1);
+ qemu_irq_raise(s-irq);
+ }
+ goto out;
+}
+bt-waiting_seq = s-inmsg[2];
+s-inmsg[2] = s-inmsg[1];
+s-handle_command(s, s-inmsg + 2, s-inlen - 2, sizeof(s-inmsg),
+ bt-waiting_rsp);
+ out:
+ipmi_unlock();
+}
+
+static void ipmi_bt_handle_rsp(IPMIState *s, uint8_t msg_id
[PATCH 2/9] pc: move SMBIOS setup to after device init
From: Corey Minyard cminy...@mvista.com
Setting up the firmware interface for the SMBIOS table needs to
be done later in the process, after device initialization, so that
devices can add entries to the table.
Signed-off-by: Corey Minyard cminy...@mvista.com
---
hw/pc.c | 22 +-
hw/pc.h |9 +
hw/pc_piix.c | 12
3 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index fb04c8b..c0acb6a 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -971,20 +971,12 @@ void pc_cpus_init(const char *cpu_model)
}
void pc_memory_init(MemoryRegion *system_memory,
-const char *kernel_filename,
-const char *kernel_cmdline,
-const char *initrd_filename,
ram_addr_t below_4g_mem_size,
ram_addr_t above_4g_mem_size,
-MemoryRegion *rom_memory,
MemoryRegion **ram_memory)
{
-int linux_boot, i;
-MemoryRegion *ram, *option_rom_mr;
+MemoryRegion *ram;
MemoryRegion *ram_below_4g, *ram_above_4g;
-void *fw_cfg;
-
-linux_boot = (kernel_filename != NULL);
/* Allocate RAM. We allocate it as a single memory region and use
* aliases to address portions of it, mostly for backwards compatibility
@@ -1006,7 +998,17 @@ void pc_memory_init(MemoryRegion *system_memory,
memory_region_add_subregion(system_memory, 0x1ULL,
ram_above_4g);
}
+}
+void pc_bios_init(const char *kernel_filename,
+ const char *kernel_cmdline,
+ const char *initrd_filename,
+ ram_addr_t below_4g_mem_size,
+ MemoryRegion *rom_memory)
+{
+MemoryRegion *option_rom_mr;
+void *fw_cfg;
+int linux_boot, i;
/* Initialize PC system firmware */
pc_system_firmware_init(rom_memory);
@@ -1019,6 +1021,8 @@ void pc_memory_init(MemoryRegion *system_memory,
option_rom_mr,
1);
+linux_boot = (kernel_filename != NULL);
+
fw_cfg = bochs_bios_init();
rom_set_fw(fw_cfg);
diff --git a/hw/pc.h b/hw/pc.h
index 8ccf202..33ab689 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -107,13 +107,14 @@ void pc_acpi_smi_interrupt(void *opaque, int irq, int
level);
void pc_cpus_init(const char *cpu_model);
void pc_memory_init(MemoryRegion *system_memory,
-const char *kernel_filename,
-const char *kernel_cmdline,
-const char *initrd_filename,
ram_addr_t below_4g_mem_size,
ram_addr_t above_4g_mem_size,
-MemoryRegion *rom_memory,
MemoryRegion **ram_memory);
+void pc_bios_init(const char *kernel_filename,
+ const char *kernel_cmdline,
+ const char *initrd_filename,
+ ram_addr_t below_4g_mem_size,
+ MemoryRegion *rom_memory);
qemu_irq *pc_allocate_cpu_irq(void);
DeviceState *pc_vga_init(ISABus *isa_bus, PCIBus *pci_bus);
void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index fb86f27..21b4f59 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -176,10 +176,8 @@ static void pc_init1(MemoryRegion *system_memory,
/* allocate ram and load rom/bios */
if (!xen_enabled()) {
-pc_memory_init(system_memory,
- kernel_filename, kernel_cmdline, initrd_filename,
- below_4g_mem_size, above_4g_mem_size,
- pci_enabled ? rom_memory : system_memory, ram_memory);
+pc_memory_init(system_memory, below_4g_mem_size, above_4g_mem_size,
+ ram_memory);
}
gsi_state = g_malloc0(sizeof(*gsi_state));
@@ -287,6 +285,12 @@ static void pc_init1(MemoryRegion *system_memory,
if (pci_enabled) {
pc_pci_device_init(pci_bus);
}
+
+if (!xen_enabled()) {
+ pc_bios_init(kernel_filename, kernel_cmdline, initrd_filename,
+below_4g_mem_size,
+pci_enabled ? rom_memory : system_memory);
+}
}
static void pc_init_pci(ram_addr_t ram_size,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] IPMI: Add a KCS low-level interface
From: Corey Minyard cminy...@mvista.com
This provides the simulation of the KCS hardware interface.
Signed-off-by: Corey Minyard cminy...@mvista.com
---
default-configs/i386-softmmu.mak |1 +
default-configs/x86_64-softmmu.mak |1 +
hw/Makefile.objs |1 +
hw/ipmi_kcs.c | 259
hw/ipmi_kcs.h | 82 +++
5 files changed, 344 insertions(+), 0 deletions(-)
create mode 100644 hw/ipmi_kcs.c
create mode 100644 hw/ipmi_kcs.h
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index c0aff0d..b549389 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -9,6 +9,7 @@ CONFIG_VMWARE_VGA=y
CONFIG_VMMOUSE=y
CONFIG_IPMI=y
CONFIG_ISA_IPMI=y
+CONFIG_IPMI_KCS=y
CONFIG_SERIAL=y
CONFIG_PARALLEL=y
CONFIG_I8254=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 615e4f2..af7d2a9 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -9,6 +9,7 @@ CONFIG_VMWARE_VGA=y
CONFIG_VMMOUSE=y
CONFIG_IPMI=y
CONFIG_ISA_IPMI=y
+CONFIG_IPMI_KCS=y
CONFIG_SERIAL=y
CONFIG_PARALLEL=y
CONFIG_I8254=y
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index 8f27ffe..99e5d1e 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -22,6 +22,7 @@ hw-obj-$(CONFIG_EMPTY_SLOT) += empty_slot.o
hw-obj-$(CONFIG_IPMI) += ipmi.o
hw-obj-$(CONFIG_ISA_IPMI) += isa_ipmi.o
+hw-obj-$(CONFIG_IPMI_KCS) += ipmi_kcs.o
hw-obj-$(CONFIG_SERIAL) += serial.o
hw-obj-$(CONFIG_PARALLEL) += parallel.o
diff --git a/hw/ipmi_kcs.c b/hw/ipmi_kcs.c
new file mode 100644
index 000..61188c9
--- /dev/null
+++ b/hw/ipmi_kcs.c
@@ -0,0 +1,259 @@
+/*
+ * QEMU IPMI KCS emulation
+ *
+ * Copyright (c) 2012 Corey Minyard, MontaVista Software, LLC
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include hw.h
+
+#include ipmi.h
+#include ipmi_kcs.h
+
+#define SET_OBF() \
+do { \
+ IPMI_KCS_SET_OBF(kcs-status_reg, 1); \
+ if (s-use_irq s-irqs_enabled !s-obf_irq_set) { \
+ s-obf_irq_set = 1; \
+ if (!s-atn_irq_set)\
+ qemu_irq_raise(s-irq); \
+ } \
+} while (0)
+
+static void ipmi_kcs_handle_event(IPMIState *s)
+{
+IPMIKcsState *kcs = s-typeinfo;
+if (kcs-cmd_reg == IPMI_KCS_ABORT_STATUS_CMD) {
+ if (IPMI_KCS_GET_STATE(kcs-status_reg) != IPMI_KCS_ERROR_STATE) {
+ kcs-waiting_rsp++; /* Invalidate the message */
+ s-outmsg[0] = IPMI_KCS_STATUS_ABORTED_ERR;
+ s-outlen = 1;
+ s-outpos = 0;
+ IPMI_KCS_SET_STATE(kcs-status_reg, IPMI_KCS_ERROR_STATE);
+ SET_OBF();
+ }
+ goto out;
+}
+
+switch (IPMI_KCS_GET_STATE(kcs-status_reg)) {
+case IPMI_KCS_IDLE_STATE:
+ if (kcs-cmd_reg == IPMI_KCS_WRITE_START_CMD) {
+ IPMI_KCS_SET_STATE(kcs-status_reg, IPMI_KCS_WRITE_STATE);
+ kcs-cmd_reg = -1;
+ s-write_end = 0;
+ s-inlen = 0;
+ SET_OBF();
+ }
+ break;
+
+case IPMI_KCS_READ_STATE:
+handle_read:
+ if (s-outpos = s-outlen) {
+ IPMI_KCS_SET_STATE(kcs-status_reg, IPMI_KCS_IDLE_STATE);
+ SET_OBF();
+ } else if (kcs-data_in_reg == IPMI_KCS_READ_CMD) {
+ kcs-data_out_reg = s-outmsg[s-outpos];
+ s-outpos++;
+ SET_OBF();
+ } else {
+ s-outmsg[0] = IPMI_KCS_STATUS_BAD_CC_ERR;
+ s-outlen = 1;
+ s-outpos = 0;
+ IPMI_KCS_SET_STATE(kcs-status_reg, IPMI_KCS_ERROR_STATE);
+ SET_OBF();
+ goto out
Re: [Qemu-devel] Adding an IPMI BMC device to KVM
On 05/18/2012 08:08 AM, Stefan Hajnoczi wrote: On Mon, May 7, 2012 at 3:30 PM, Anthony Liguorianth...@codemonkey.ws wrote: On 05/06/2012 09:39 AM, Avi Kivity wrote: On 05/06/2012 05:35 PM, Anthony Liguori wrote: So what's really the use case here? Would an IPMI - libvirt bridge get you what you need? I really think that's the best path forward. Sorry for sending this twice. I thought my mailer was set to disable HTML. Many of our customer use the standard watchdog timer and power controls on IPMI. Basically, the watchdog timer needs to be able to power off, power cycle, reset, and send an NMI. The IPMI watchdog can be configured to do all those things. (The NMI is for a pretimeout that generally triggers a panic.) Power control is no big surprise. It's true that you have ACPI to do this, but that's not terribly useful on non-x86 (and non ia64, I suppose) systems. Do you want to expose host sensors - the challenge is that they don't reflect the hardware that the virtual machine sees? Or do you want to have synthetic sensors - which virtual sensors are useful to have? A few sensors, notably the watchdog timer sensor, are not synthetic. The others generally are. Sensors cover things beyond just power and temperature. Important other ones in IPMI deal with the presence of FRUs in the system, BIOS/OS state, and intrusion detection. Two main reasons for synthesized sensors exist. One, in a legacy situation, is to fool the management system into thinking everything is ok, since it is expecting to see these sensors with specific values. You could even possibly reflect the state of real sensors, mapping them somehow, if you wanted. The other reason is for testing. It's pretty hard to induce some of these sensors to go out of range in a real system. So without simulation, you need a hack-ed up management controller in a real system to truly test your software. Is the IPMI watchdog useful, QEMU already supports the i6300esb PCI watchdog (see qemu -watchdog option documentation)? That's only useful if you can simulate an i6300esb. Probably not possible on non-x86. Plus legacy systems may be expecting the capabilities of the IPMI watchdog. Some use cases that illustrate how the guest is going to use IPMI would be interesting and could help guide the discussion. You are probably right. I've mentioned a couple above. One other possible one, that someone else mentioned, is the ability to control a VM using standard tools like ipmitool or OpenIPMI over network interfaces. People may already have management systems that are designed around IPMI, and it would make a move to virtual machines easier. This was the request mentioned that was in the Redhat database. Such a capability would require re-thinking things a bit. You have two basic options that I see. Either have the management controller run outside qemu and define a simple interface to it, or modify qemu to be able to run the management controller internally. My preference in to run it outside qemu, for the following reasons: * It decouples things that are IPMI internals from having to go through getting into qemu repositories. * The management controller then becomes useful for a number of other purposes. I already have one mostly done that I use for testing. It could be used by other VMs. * A full management controller is a fairly big piece of software, especially if you include the network access. It probably doesn't belong in qemu. * No offense, I don't want to muck around inside qemu to accomplish this :). There are, of course, disadvantages. Some I can think of: * There can be confusion about which versions of two things work together. * Overall, it is more complex to get working. * There are possible security implications. So I guess those are points we can talk about... -corey -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Adding an IPMI BMC device to KVM
I think we are getting a little out of hand here, and we are mixing up concepts :). There are lots of things IPMI *can* do (including serial access, VGA snooping, LAN access, etc.) but I don't see any value it that. The main thing here is to emulate the interface to the guest. OOB management is really more appropriately handled with libvirt. How the BMC integrates into the hardware varies a *lot* between systems, but it's really kind of irrelevant. (Well, almost irrelevant, BMCs can provide a direct I2C messaging capability, and that may matter.) A guest can have one (or more) of a number of interfaces (that are all fairly bad, unfortunately). The standard ones are called KCS, BT and SMIC and they generally are directly on the ISA bus, but are in memory on non-x86 boxes (and on some x86 boxes) and sometimes on the PCI bus. Some systems also have interfaces over I2C, but that hasn't really caught on. Others have interfaces over serial ports, and that unfortunately has caught on in the ATCA world. And there are at least 3 different basic types of serial port interfaces with sub-variants :(. I'm not sure what the USB rndis device is, but I'll look at it. But there is no IPMI over USB. The big things a guest can do are sensor management, watchdog timer, reset, and power control. In complicated IPMI-based systems like ATCA, a guest may want to send messages through its local IPMI controller to other guest's IPMI controllers or to a central BMC that runs an entire chassis of systems. So that may need to be supported, depending on what people want to do and how hard they want to work on it. My proposal is to start small, with just a local interface, watchdog timer, sensors and power control. But have an architecture that would allow external LAN access, tying BMCs in different qemu instances together, perhaps serial over IPMI, and other things of that nature. -corey On 05/07/2012 10:21 AM, Anthony Liguori wrote: On 05/07/2012 10:11 AM, Avi Kivity wrote: On 05/07/2012 05:55 PM, Anthony Liguori wrote: For all intents and purposes, the BMC/RSA is a separate physical machine. That's true for any other card on a machine. It has a separate power source for all intents and purposes. If you think of it in QOM terms, what connects the nodes together ultimately is the Vcc pin that travels across all devices. The RTC is a little special because it has a battery backed CMOS/clock but it's also handled specially. And we fail to emulate it correctly as well, wrt. alarms. The BMC does not share Vcc. It's no different than a separate physical box. It just shares a couple buses. It controls the main power place, reset line, can read VGA and emulate keyboard, seems pretty well integrated. Emulating the keyboard is done through USB. How the VGA thing works is very vendor dependent. The VGA snooping can happen as part of the display path (essentially connected via a VGA cable) or it can be a side-band using a special graphics adapter. I think QEMU VNC emulation is a pretty good analogy actually. That is one way to do it. Figure out the interactions between two different parts in a machine, define an interface for them to communicate, and split them into two processes. We don't usually do that; I believe your motivation is that the two have different power domains (but then so do NICs with wake-on-LAN support). The power still comes from the PCI bus. Maybe. But it's on when the rest of the machine is off. So Vcc is not shared. That's all plumbed through the PCI bus FWIW. Think of something like a blade center. Each individual blade does not have it's own BMC. There's a single common BMC that provides an IPMI interface for all blades. Yet each blade still sees an IPMI interface via a USB rndis device. You can rip out the memory, PCI devices, etc. from a box while the Power is in and the BMC will be unaffected. At any rate, you would have some sort of virtual hardware device that essentially spoke QMP to the slave instance. You could just do virtio-serial and call it a day actually. Sorry I lost you. Which is the master and which is the slave? The BMC is the master, system being controlled is the slave. Ah okay. It also has to read the VGA output (say via vnc) and supply keyboard input (via sendkey). Right, QMP + VNC is a pretty accurate analogy. It really boils down to what you are trying to do. If you want to just get some piece of software working that expects to do IPMI, the easiest thing to do is run IPMI in the host and use a USB rndis interface to interact with it. That would be most strange. A remote client connecting to the IPMI interface would control the power level of the host, not the guest. IPMI with a custom backend is what I mean. That's what I mean by an IPMI - libvirt bridge. You could build a libvirt client that exposes an IPMI interface and when you issue IPMI commands, it translate it to
Re: [Qemu-devel] Adding an IPMI BMC device to KVM
On 05/07/2012 02:45 PM, Dave Allan wrote: FWIW, the idea of an IPMI interface to VMs was proposed for libvirt not too long ago. See: https://bugzilla.redhat.com/show_bug.cgi?id=815136 Well, it wouldn't be to hard to do. I already have working emulation code that does the IPMI LAN interface (including the IPMI 2.0 stuff for more reasonable security). I have a KCS interface and a minimal IPMI controller working in KVM, though I'm not quite sure the best final way to hook it in. Configuration is going to be the hardest part, but a minimal configuration for providing basic management would be easy. -corey Dave On Mon, May 07, 2012 at 01:07:45PM -0500, Corey Minyard wrote: I think we are getting a little out of hand here, and we are mixing up concepts :). There are lots of things IPMI *can* do (including serial access, VGA snooping, LAN access, etc.) but I don't see any value it that. The main thing here is to emulate the interface to the guest. OOB management is really more appropriately handled with libvirt. How the BMC integrates into the hardware varies a *lot* between systems, but it's really kind of irrelevant. (Well, almost irrelevant, BMCs can provide a direct I2C messaging capability, and that may matter.) A guest can have one (or more) of a number of interfaces (that are all fairly bad, unfortunately). The standard ones are called KCS, BT and SMIC and they generally are directly on the ISA bus, but are in memory on non-x86 boxes (and on some x86 boxes) and sometimes on the PCI bus. Some systems also have interfaces over I2C, but that hasn't really caught on. Others have interfaces over serial ports, and that unfortunately has caught on in the ATCA world. And there are at least 3 different basic types of serial port interfaces with sub-variants :(. I'm not sure what the USB rndis device is, but I'll look at it. But there is no IPMI over USB. The big things a guest can do are sensor management, watchdog timer, reset, and power control. In complicated IPMI-based systems like ATCA, a guest may want to send messages through its local IPMI controller to other guest's IPMI controllers or to a central BMC that runs an entire chassis of systems. So that may need to be supported, depending on what people want to do and how hard they want to work on it. My proposal is to start small, with just a local interface, watchdog timer, sensors and power control. But have an architecture that would allow external LAN access, tying BMCs in different qemu instances together, perhaps serial over IPMI, and other things of that nature. -corey On 05/07/2012 10:21 AM, Anthony Liguori wrote: On 05/07/2012 10:11 AM, Avi Kivity wrote: On 05/07/2012 05:55 PM, Anthony Liguori wrote: For all intents and purposes, the BMC/RSA is a separate physical machine. That's true for any other card on a machine. It has a separate power source for all intents and purposes. If you think of it in QOM terms, what connects the nodes together ultimately is the Vcc pin that travels across all devices. The RTC is a little special because it has a battery backed CMOS/clock but it's also handled specially. And we fail to emulate it correctly as well, wrt. alarms. The BMC does not share Vcc. It's no different than a separate physical box. It just shares a couple buses. It controls the main power place, reset line, can read VGA and emulate keyboard, seems pretty well integrated. Emulating the keyboard is done through USB. How the VGA thing works is very vendor dependent. The VGA snooping can happen as part of the display path (essentially connected via a VGA cable) or it can be a side-band using a special graphics adapter. I think QEMU VNC emulation is a pretty good analogy actually. That is one way to do it. Figure out the interactions between two different parts in a machine, define an interface for them to communicate, and split them into two processes. We don't usually do that; I believe your motivation is that the two have different power domains (but then so do NICs with wake-on-LAN support). The power still comes from the PCI bus. Maybe. But it's on when the rest of the machine is off. So Vcc is not shared. That's all plumbed through the PCI bus FWIW. Think of something like a blade center. Each individual blade does not have it's own BMC. There's a single common BMC that provides an IPMI interface for all blades. Yet each blade still sees an IPMI interface via a USB rndis device. You can rip out the memory, PCI devices, etc. from a box while the Power is in and the BMC will be unaffected. At any rate, you would have some sort of virtual hardware device that essentially spoke QMP to the slave instance. You could just do virtio-serial and call it a day actually. Sorry I lost you. Which is the master and which is the slave? The BMC is the master, system being controlled is the slave. Ah okay. It also has to read the VGA output (say via vnc) and supply keyboard input (via
Fwd: Re: Adding an IPMI BMC device to KVM
Resending to the list, plan text only. Sorry about that... Original Message Subject:Re: Adding an IPMI BMC device to KVM Date: Mon, 07 May 2012 16:57:06 -0500 From: Corey Minyard tcminy...@gmail.com Reply-To: miny...@acm.org To: Anthony Liguori anth...@codemonkey.ws CC: kvm@vger.kernel.org, Avi Kivity a...@redhat.com On 05/05/2012 09:29 AM, Anthony Liguori wrote: You could just use a USB rndis device and then run an IPMI server on the host. That is probably the simpliest way to test. I'm trying to figure out how RNDIS would be helpful here. You can't have the guest talk USB for this, it's going to talk the standard interfaces. However, I am loathe to create my own protocol for talking between the BMC and QEMU. Perhaps RNDIS could be useful, but it's massive overkill. It also doesn't provide any security. If there were client and server libraries that would run over a socket, that would be tempting. I'm wondering if security is that big a deal, though. If you use a chardev, and you have QEMU make a connection to the BMC, maybe that would be ok. BMCs typically run a full OS like Linux making emulation as a device in QEMU prohibitively hard. BMCs are generally very simple 8-bit microcontrollers, unless they are something like an ATCA shelf manager. Emulation is pretty easy. Well, emulation of an ATCA shelf manager wouldn't be easy, but that's hopefully not required in the near future. -corey Regards, Anthony Liguori On May 4, 2012 2:10 PM, Corey Minyard tcminy...@gmail.com mailto:tcminy...@gmail.com wrote: I've been working on adding an IPMI BMC as a virtual device under KVM. I'm doing this for two primary reasons, one to have a better test environment than what I have now for testing IPMI issues, and second to be able to better simulate a legacy environment for customers porting legacy software. For those that don't know, IPMI is a system management interface. Generally systems with IPMI have a small microcontroller, called a BMC, that is always on when the board is powered. The BMC is capable of controlling power and reset on the board, and it is hooked to sensors on the board (voltage, current, temperature, the presence of things like DIMMS and power supplies, intrusion detection, and a host of other things). The main processor on a system can communicate with the BMC over a device. Often these systems also have a LAN interface that lets you control the system remotely even when it's off. In addition, IPMI provides access to FRU (Field Replaceable Unit) data that describes the components of the system that can be replaced. It also has data records that describe the sensor, so it is possible to directly interpret the sensor data and know what the sensor is measuring without outside data. I've been struggling a bit with how to implement this. There is a lot of configuration information, and you need ways to simulate the sensors. This type of interface is a little sensitive, since it has direct access to the reset and power control of a system. I was at first considering having the BMC be an external program that KVM connected to over a chardev, with possibly a simulated LAN interface. This has the advantage that the BMC can run even when KVM is down. It could even start up KVM for a power up, though I'm not sure how valuable that would be. Plus it could be used for other virtual machines. However, that means there is an interface to KVM over a chardev that could do nasty things, and even be a possible intrusion point. It also means there is a separate program to maintain. You could also include the BMC inside of KVM and run it as a separate thread. That way there doesn't have to be an insecure interface. But the BMC will need a lot of configuration data and this will add a bunch of code to KVM that's only tangentially related to it. And you would still need a way to simulate setting sensors and such for testing things. Either way, is this interesting for including into KVM? Does anyone have any opinions on the possible ways to implement this? Thanks, -corey -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org mailto:majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Adding an IPMI BMC device to KVM
I've been working on adding an IPMI BMC as a virtual device under KVM. I'm doing this for two primary reasons, one to have a better test environment than what I have now for testing IPMI issues, and second to be able to better simulate a legacy environment for customers porting legacy software. For those that don't know, IPMI is a system management interface. Generally systems with IPMI have a small microcontroller, called a BMC, that is always on when the board is powered. The BMC is capable of controlling power and reset on the board, and it is hooked to sensors on the board (voltage, current, temperature, the presence of things like DIMMS and power supplies, intrusion detection, and a host of other things). The main processor on a system can communicate with the BMC over a device. Often these systems also have a LAN interface that lets you control the system remotely even when it's off. In addition, IPMI provides access to FRU (Field Replaceable Unit) data that describes the components of the system that can be replaced. It also has data records that describe the sensor, so it is possible to directly interpret the sensor data and know what the sensor is measuring without outside data. I've been struggling a bit with how to implement this. There is a lot of configuration information, and you need ways to simulate the sensors. This type of interface is a little sensitive, since it has direct access to the reset and power control of a system. I was at first considering having the BMC be an external program that KVM connected to over a chardev, with possibly a simulated LAN interface. This has the advantage that the BMC can run even when KVM is down. It could even start up KVM for a power up, though I'm not sure how valuable that would be. Plus it could be used for other virtual machines. However, that means there is an interface to KVM over a chardev that could do nasty things, and even be a possible intrusion point. It also means there is a separate program to maintain. You could also include the BMC inside of KVM and run it as a separate thread. That way there doesn't have to be an insecure interface. But the BMC will need a lot of configuration data and this will add a bunch of code to KVM that's only tangentially related to it. And you would still need a way to simulate setting sensors and such for testing things. Either way, is this interesting for including into KVM? Does anyone have any opinions on the possible ways to implement this? Thanks, -corey -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying panic happened, like sending stack traces on all cpus for instance. I doubt that's the best example, unfortunately. The IPMI event log has limited space and it has to be send a little piece at a time since each log entry is 14 bytes. It just prints the panic string, nothing else. Not that it isn't useful, it has saved my butt before. You have lots of interesting options with paravirtualization. You could, for instance, create a console driver that delivered all console output efficiently through a hypercall. That would be really easy. Or, as you mention, a custom way to deliver panic information. Collecting information like stack traces would be harder to accomplish, as I don't think there is currently a way to get it except by sending it to printk. -corey -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM on 440GP
I'm playing around with KVM on an ebony board (440GP), just trying to
get it to work, really. I followed the instructions at
http://www.linux-kvm.org/page/PowerPC and I used the 2.6.33 branch of
the kvm kernel repository. When I try to run kvm, qemu appears to abort
and actually logs me off.
Doing a little debugging, I found that qemu_memalign() is calling abort
because posix_memalign() is failing. I haven't done any more debugging
than that.
Since I already had to fix a kernel issue to get it the kernel code to
initialize since the platform was reported as ppc440gp, not ppc440, I'm
wondering how hard it's going to be to get this working. Does anyone
have this working at all? Should I back up to a previous version? Any
help would be appreciated.
Thanks,
-corey
Here's the change I made to get kvm in the kernel to initialize:
Index: kvm/arch/powerpc/kvm/44x.c
===
--- kvm.orig/arch/powerpc/kvm/44x.c
+++ kvm/arch/powerpc/kvm/44x.c
@@ -42,7 +42,7 @@ int kvmppc_core_check_processor_compat(v
{
int r;
- if (strcmp(cur_cpu_spec-platform, ppc440) == 0)
+ if (strncmp(cur_cpu_spec-platform, ppc440, 6) == 0)
r = 0;
else
r = -ENOTSUPP;
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM on 440GP
Corey Minyard wrote:
I'm playing around with KVM on an ebony board (440GP), just trying to
get it to work, really. I followed the instructions at
http://www.linux-kvm.org/page/PowerPC and I used the 2.6.33 branch of
the kvm kernel repository. When I try to run kvm, qemu appears to
abort and actually logs me off.
Doing a little debugging, I found that qemu_memalign() is calling
abort because posix_memalign() is failing. I haven't done any more
debugging than that.
Well, I discovered that the default memory is 128M, and that's too much
memory for a VM running on a machine with 128M. I fixed that problem,
and now it's doing something, though no console so not sure what.
I guess my questions below and the patch still apply.
-corey
Since I already had to fix a kernel issue to get it the kernel code to
initialize since the platform was reported as ppc440gp, not ppc440,
I'm wondering how hard it's going to be to get this working. Does
anyone have this working at all? Should I back up to a previous
version? Any help would be appreciated.
Thanks,
-corey
Here's the change I made to get kvm in the kernel to initialize:
Index: kvm/arch/powerpc/kvm/44x.c
===
--- kvm.orig/arch/powerpc/kvm/44x.c
+++ kvm/arch/powerpc/kvm/44x.c
@@ -42,7 +42,7 @@ int kvmppc_core_check_processor_compat(v
{
int r;
- if (strcmp(cur_cpu_spec-platform, ppc440) == 0)
+ if (strncmp(cur_cpu_spec-platform, ppc440, 6) == 0)
r = 0;
else
r = -ENOTSUPP;
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM on 440GP
Hollis Blanchard wrote: Thanks! The patch looks good to me. It's unfortunate that 440GP is reported is ppc440gp, while every other 440 variant is reported is ppc440, but that's just how it goes I guess. It shouldn't be too difficult to get things working, since the cores are more or less the same. There has been a little accidental build breakage introduced in the 440 code recently (work to support the Book S KVM port), but it's all been simple stuff. There's more basic build problems with the kernel at the head of development, but that doesn't seem related to kvm. As for console, you probably want to use qemu's -nographic or at least -serial stdio options. Thanks for the info. However, -serial stdio doesn't seem to work. I get: r...@ebony:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 128 -M bamboo -kernel uImage.bamboo -L . -append -m 64 -serial stdio chardev: opening backend stdio failed qemu: could not open serial device 'stdio': Success I'm using the qemu at git://git.savannah.nongnu.org/qemu.git, not the one at git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git, because the latter wouldn't build. I suppose those are the build problems you speak of. I'll see if I can get the latter working. Thanks a bunch! -corey -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM on 440GP
Alexander Graf wrote: I'm using the qemu at git://git.savannah.nongnu.org/qemu.git, not the one at git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git, because the latter wouldn't build. I suppose those are the build problems you speak of. I'll see if I can get the latter working. That's the correct one. I assume you mean git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git is the correct one. There's lots of problems getting it to compile. There's no support in target-ppc for KVM_CAP_MP_STATE, so I'm currently backing up kernels until I find one that doesn't have that capability. Thanks, -corey -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM on 440GP
Alexander Graf wrote: On 22.01.2010, at 19:29, Corey Minyard wrote: Alexander Graf wrote: I'm using the qemu at git://git.savannah.nongnu.org/qemu.git, not the one at git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git, because the latter wouldn't build. I suppose those are the build problems you speak of. I'll see if I can get the latter working. That's the correct one. I assume you mean git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git is the correct one. There's lots of problems getting it to compile. There's no support in target-ppc for KVM_CAP_MP_STATE, so I'm currently backing up kernels until I find one that doesn't have that capability. I mean git://git.savannah.nongnu.org/qemu.git is the correct one. The KVM support in qemu-kvm is broken. Same as for S390 :-). Alex Ah, ok, then I am using the right one. I tried using telnet for the console, and it worked for a little while: r...@ebony:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 128 -M bamb oo -kernel uImage.bamboo -L . -append -m 64 -serial tcp::,server QEMU waiting for connection on: tcp:0.0.0.0:,server Truncating memory to 64 MiB to fit SDRAM controller limits. QEMU 0.12.50 monitor - type 'help' for more information (qemu) info kvm kvm support: enabled (qemu) So things are getting closer, but there's no output on the telnet screen. Doing an info registers causes qemu to abort. Now, nothing should have changed, but it's crashing at startup: r...@ebony:~# ./qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uI mage.bamboo -L . -append -m 64 -serial tcp::,server QEMU waiting for connection on: tcp:0.0.0.0:,server Truncating memory to 64 MiB to fit SDRAM controller limits. QEMU 0.12.0 monitor - type 'help' for more information (qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 0x NIP LR CTR XER MSR HID0 0300 HF idx 0 Segmentatio backtrace show the invalid memory address, and the segfault is due to something happening while printing out the information. Still poking around. -corey -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
