Hi all, This series back-port recently added QEMU patches to our qemu-xen. The interface between the guest and QEMU is the same as with qemu-traditional. Only the interface between libxl and qemu change, instead of xenstore we are using QMP to hotplug vcpus. Three more patches will follow this series. - two for libxl which implement the QMP command cpu-add. - one for SeaBIOS which workaround a bug. When using adding vcpus with this series, libxl will report many "error". This is because libxl call the QMP command ''cpu-add'' for every plugged vcpus, even those that have been plugged before. There is currently no way to list cpus that are plugged by QEMU. Also, the ways errors are handle by libxl_qmp those not help yet to suppress this error printing. Unplug of vcpu is not supported by the series. Change since the first set: - back-port of QEMU patches instead of forth-port from qemu-traditional - added a SeaBIOS patch Regards, Anthony PERARD (2): xen: Fix vcpus initialisation. xen: Implement hot_add_cpu hook. Igor Mammedov (4): cpu: Introduce get_arch_id() method and override it for X86CPU acpi_piix4: Add infrastructure to send CPU hot-plug GPE to guest Add hot_add_cpu hook to QEMUMachine QMP: Add cpu-add command Michael S. Tsirkin (1): cpu: Add qemu_for_each_cpu() docs/specs/acpi_cpu_hotplug.txt | 22 +++++++++ exec.c | 10 ++++ hw/acpi_piix4.c | 101 +++++++++++++++++++++++++++++++++++++++- hw/boards.h | 3 ++ hw/pc_piix.c | 1 + include/qemu/cpu.h | 11 +++++ qapi-schema.json | 13 ++++++ qmp-commands.hx | 23 +++++++++ qmp.c | 10 ++++ qom/cpu.c | 8 ++++ sysemu.h | 2 + target-i386/cpu.c | 10 ++++ xen-all.c | 8 ++-- 13 files changed, 216 insertions(+), 6 deletions(-) create mode 100644 docs/specs/acpi_cpu_hotplug.txt -- Anthony PERARD
Anthony PERARD
2013-Jun-17 14:15 UTC
[PATCH 1/7] cpu: Introduce get_arch_id() method and override it for X86CPU
From: Igor Mammedov <imammedo@redhat.com>
get_arch_id() adds possibility for generic code to get a guest-visible
CPU ID without accessing CPUArchState.
If derived classes don't override it, it will return cpu_index.
Override it on target-i386 in X86CPU to return the APIC ID.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: liguang <lig.fnst@cn.fujitsu.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
(cherry picked from QEMU commit 997395d3888fcde6ce41535a8208d7aa919d824b)
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
include/qemu/cpu.h | 2 ++
qom/cpu.c | 8 ++++++++
target-i386/cpu.c | 10 ++++++++++
3 files changed, 20 insertions(+)
diff --git a/include/qemu/cpu.h b/include/qemu/cpu.h
index 61b7698..8d2e0cb 100644
--- a/include/qemu/cpu.h
+++ b/include/qemu/cpu.h
@@ -41,6 +41,7 @@ typedef struct CPUState CPUState;
/**
* CPUClass:
* @reset: Callback to reset the #CPUState to its initial state.
+ * @get_arch_id: Callback for getting architecture-dependent CPU ID.
*
* Represents a CPU family or model.
*/
@@ -50,6 +51,7 @@ typedef struct CPUClass {
/*< public >*/
void (*reset)(CPUState *cpu);
+ int64_t (*get_arch_id)(CPUState *cpu);
} CPUClass;
/**
diff --git a/qom/cpu.c b/qom/cpu.c
index 5b36046..dfd14c8 100644
--- a/qom/cpu.c
+++ b/qom/cpu.c
@@ -34,11 +34,19 @@ static void cpu_common_reset(CPUState *cpu)
{
}
+static int64_t cpu_common_get_arch_id(CPUState *cpu)
+{
+ /* Not used in Xen, so no backport.
+ * There is a missing cpu_index field in CPUState. */
+ abort();
+}
+
static void cpu_class_init(ObjectClass *klass, void *data)
{
CPUClass *k = CPU_CLASS(klass);
k->reset = cpu_common_reset;
+ k->get_arch_id = cpu_common_get_arch_id;
}
static TypeInfo cpu_type_info = {
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index c6c2ca0..e055d69 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -2111,6 +2111,14 @@ static void x86_cpu_initfn(Object *obj)
}
}
+static int64_t x86_cpu_get_arch_id(CPUState *cs)
+{
+ X86CPU *cpu = X86_CPU(cs);
+ CPUX86State *env = &cpu->env;
+
+ return env->cpuid_apic_id;
+}
+
static void x86_cpu_common_class_init(ObjectClass *oc, void *data)
{
X86CPUClass *xcc = X86_CPU_CLASS(oc);
@@ -2118,6 +2126,8 @@ static void x86_cpu_common_class_init(ObjectClass *oc,
void *data)
xcc->parent_reset = cc->reset;
cc->reset = x86_cpu_reset;
+
+ cc->get_arch_id = x86_cpu_get_arch_id;
}
static const TypeInfo x86_cpu_type_info = {
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
From: "Michael S. Tsirkin" <mst@redhat.com>
Wrapper to avoid open-coded loops and to make CPUState iteration
independent of CPUArchState.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
(cherry picked from QEMU commit d6b9e0d60cc511eca210834428bb74508cff3d33)
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
exec.c | 10 ++++++++++
include/qemu/cpu.h | 9 +++++++++
2 files changed, 19 insertions(+)
diff --git a/exec.c b/exec.c
index 8435de0..9fb6927 100644
--- a/exec.c
+++ b/exec.c
@@ -692,6 +692,16 @@ CPUArchState *qemu_get_cpu(int cpu)
return env;
}
+void qemu_for_each_cpu(void (*func)(CPUState *cpu, void *data), void *data)
+{
+ CPUArchState *env = first_cpu;
+
+ while (env) {
+ func(ENV_GET_CPU(env), data);
+ env = env->next_cpu;
+ }
+}
+
void cpu_exec_init(CPUArchState *env)
{
#ifndef CONFIG_USER_ONLY
diff --git a/include/qemu/cpu.h b/include/qemu/cpu.h
index 8d2e0cb..23b8b6f 100644
--- a/include/qemu/cpu.h
+++ b/include/qemu/cpu.h
@@ -138,5 +138,14 @@ bool cpu_is_stopped(CPUState *cpu);
*/
void run_on_cpu(CPUState *cpu, void (*func)(void *data), void *data);
+/**
+ * qemu_for_each_cpu:
+ * @func: The function to be executed.
+ * @data: Data to pass to the function.
+ *
+ * Executes @func for each CPU.
+ */
+void qemu_for_each_cpu(void (*func)(CPUState *cpu, void *data), void *data);
+
#endif
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Anthony PERARD
2013-Jun-17 14:15 UTC
[PATCH 3/7] acpi_piix4: Add infrastructure to send CPU hot-plug GPE to guest
From: Igor Mammedov <imammedo@redhat.com>
* introduce processor status bitmask visible to guest at 0xaf00 addr,
where ACPI asl code expects it
* set bit corresponding to APIC ID in processor status bitmask on
receiving CPU hot-plug notification
* trigger CPU hot-plug SCI, to notify guest about CPU hot-plug event
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
(cherry picked from QEMU commit b8622725cf0196f672f272922b0941dc8ba1c408)
The function piix4_cpu_hotplug_req() has been modified to take an integer
instead of a CPU object.
There was a cpu_added_notifier in the original commit, this haven't
been back-ported, as it can't be used.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
docs/specs/acpi_cpu_hotplug.txt | 22 ++++++++++++
hw/acpi_piix4.c | 80 +++++++++++++++++++++++++++++++++++++++--
2 files changed, 100 insertions(+), 2 deletions(-)
create mode 100644 docs/specs/acpi_cpu_hotplug.txt
diff --git a/docs/specs/acpi_cpu_hotplug.txt b/docs/specs/acpi_cpu_hotplug.txt
new file mode 100644
index 0000000..5dec0c5
--- /dev/null
+++ b/docs/specs/acpi_cpu_hotplug.txt
@@ -0,0 +1,22 @@
+QEMU<->ACPI BIOS CPU hotplug interface
+--------------------------------------
+
+QEMU supports CPU hotplug via ACPI. This document
+describes the interface between QEMU and the ACPI BIOS.
+
+ACPI GPE block (IO ports 0xafe0-0xafe3, byte access):
+-----------------------------------------
+
+Generic ACPI GPE block. Bit 2 (GPE.2) used to notify CPU
+hot-add/remove event to ACPI BIOS, via SCI interrupt.
+
+CPU present bitmap (IO port 0xaf00-0xae1f, 1-byte access):
+---------------------------------------------------------------
+One bit per CPU. Bit position reflects corresponding CPU APIC ID.
+Read-only.
+
+CPU hot-add/remove notification:
+-----------------------------------------------------
+QEMU sets/clears corresponding CPU bit on hot-add/remove event.
+CPU present map read by ACPI BIOS GPE.2 handler to notify OS of CPU
+hot-(un)plug events.
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 519269a..56d7c2c 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -28,6 +28,7 @@
#include "range.h"
#include "ioport.h"
#include "fw_cfg.h"
+#include "qemu/cpu.h"
//#define DEBUG
@@ -46,16 +47,26 @@
#define PCI_EJ_BASE 0xae08
#define PCI_RMV_BASE 0xae0c
+#define PIIX4_PROC_BASE 0xaf00
+#define PIIX4_PROC_LEN 32
+
#define PIIX4_PCI_HOTPLUG_STATUS 2
+#define PIIX4_CPU_HOTPLUG_STATUS 4
struct pci_status {
uint32_t up; /* deprecated, maintained for migration compatibility */
uint32_t down;
};
+typedef struct CPUStatus {
+ uint8_t sts[PIIX4_PROC_LEN];
+} CPUStatus;
+
typedef struct PIIX4PMState {
PCIDevice dev;
IORange ioport;
+
+ MemoryRegion io_cpu;
ACPIREGS ar;
APMState apm;
@@ -77,6 +88,8 @@ typedef struct PIIX4PMState {
uint8_t disable_s3;
uint8_t disable_s4;
uint8_t s4_val;
+
+ CPUStatus gpe_cpu;
} PIIX4PMState;
static void piix4_acpi_system_hot_add_init(PCIBus *bus, PIIX4PMState *s);
@@ -94,8 +107,8 @@ static void pm_update_sci(PIIX4PMState *s)
ACPI_BITMASK_POWER_BUTTON_ENABLE |
ACPI_BITMASK_GLOBAL_LOCK_ENABLE |
ACPI_BITMASK_TIMER_ENABLE)) != 0) ||
- (((s->ar.gpe.sts[0] & s->ar.gpe.en[0])
- & PIIX4_PCI_HOTPLUG_STATUS) != 0);
+ (((s->ar.gpe.sts[0] & s->ar.gpe.en[0]) &
+ (PIIX4_PCI_HOTPLUG_STATUS | PIIX4_CPU_HOTPLUG_STATUS)) != 0);
qemu_set_irq(s->irq, sci_level);
/* schedule a timer interruption if needed */
@@ -602,6 +615,63 @@ static uint32_t pcirmv_read(void *opaque, uint32_t addr)
return s->pci0_hotplug_enable;
}
+static uint64_t cpu_status_read(void *opaque, hwaddr addr, unsigned int size)
+{
+ PIIX4PMState *s = opaque;
+ CPUStatus *cpus = &s->gpe_cpu;
+ uint64_t val = cpus->sts[addr];
+
+ return val;
+}
+
+static void cpu_status_write(void *opaque, hwaddr addr, uint64_t data,
+ unsigned int size)
+{
+ /* TODO: implement VCPU removal on guest signal that CPU can be removed */
+}
+
+static const MemoryRegionOps cpu_hotplug_ops = {
+ .read = cpu_status_read,
+ .write = cpu_status_write,
+ .endianness = DEVICE_LITTLE_ENDIAN,
+ .valid = {
+ .min_access_size = 1,
+ .max_access_size = 1,
+ },
+};
+
+typedef enum {
+ PLUG,
+ UNPLUG,
+} HotplugEventType;
+
+static void piix4_cpu_hotplug_req(PIIX4PMState *s, int64_t cpu_id,
+ HotplugEventType action)
+{
+ CPUStatus *g = &s->gpe_cpu;
+ ACPIGPE *gpe = &s->ar.gpe;
+
+ assert(s != NULL);
+
+ *gpe->sts = *gpe->sts | PIIX4_CPU_HOTPLUG_STATUS;
+ if (action == PLUG) {
+ g->sts[cpu_id / 8] |= (1 << (cpu_id % 8));
+ } else {
+ g->sts[cpu_id / 8] &= ~(1 << (cpu_id % 8));
+ }
+ pm_update_sci(s);
+}
+
+static void piix4_init_cpu_status(CPUState *cpu, void *data)
+{
+ CPUStatus *g = (CPUStatus *)data;
+ CPUClass *k = CPU_GET_CLASS(cpu);
+ int64_t id = k->get_arch_id(cpu);
+
+ g_assert((id / 8) < PIIX4_PROC_LEN);
+ g->sts[id / 8] |= (1 << (id % 8));
+}
+
static int piix4_device_hotplug(DeviceState *qdev, PCIDevice *dev,
PCIHotplugState state);
@@ -621,6 +691,12 @@ static void piix4_acpi_system_hot_add_init(PCIBus *bus,
PIIX4PMState *s)
register_ioport_read(PCI_RMV_BASE, 4, 4, pcirmv_read, s);
pci_bus_hotplug(bus, piix4_device_hotplug, &s->dev.qdev);
+
+ qemu_for_each_cpu(piix4_init_cpu_status, &s->gpe_cpu);
+ memory_region_init_io(&s->io_cpu, &cpu_hotplug_ops, s,
"apci-cpu-hotplug",
+ PIIX4_PROC_LEN);
+ memory_region_add_subregion(pci_address_space_io(&s->dev),
+ PIIX4_PROC_BASE, &s->io_cpu);
}
static void enable_device(PIIX4PMState *s, int slot)
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
From: Igor Mammedov <imammedo@redhat.com>
Hook should be set by machines that implement CPU hot-add
via cpu-add QMP command.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
(cherry picked from QEMU commit b4fc7b4326112538e0dbdc7fd019652ba8cc3281)
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
hw/boards.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/boards.h b/hw/boards.h
index 813d0e5..64931bc 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -18,6 +18,8 @@ typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args);
typedef void QEMUMachineResetFunc(void);
+typedef void QEMUMachineHotAddCPUFunc(const int64_t id, Error **errp);
+
typedef struct QEMUMachine {
const char *name;
const char *alias;
@@ -25,6 +27,7 @@ typedef struct QEMUMachine {
QEMUMachineInitFunc *init;
QEMUMachineResetFunc *reset;
int use_scsi;
+ QEMUMachineHotAddCPUFunc *hot_add_cpu;
int max_cpus;
unsigned int no_serial:1,
no_parallel:1,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
From: Igor Mammedov <imammedo@redhat.com>
Adds "cpu-add id=xxx" QMP command.
cpu-add's "id" argument is a CPU number in a range [0..max-cpus)
Example QMP command:
-> { "execute": "cpu-add", "arguments": {
"id": 2 } }
<- { "return": {} }
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
(cherry picked from QEMU commit 69ca3ea5e192251f27510554611bcff6f036a00b)
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
qapi-schema.json | 13 +++++++++++++
qmp-commands.hx | 23 +++++++++++++++++++++++
qmp.c | 10 ++++++++++
3 files changed, 46 insertions(+)
diff --git a/qapi-schema.json b/qapi-schema.json
index 5dfa052..64cecbe 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1284,6 +1284,19 @@
{ 'command': 'cpu', 'data': {'index':
'int'} }
##
+# @cpu-add
+#
+# Adds CPU with specified ID
+#
+# @id: ID of CPU to be created, valid values [0..max_cpus)
+#
+# Returns: Nothing on success
+#
+# Since 1.5
+##
+{ 'command': 'cpu-add', 'data': {'id':
'int'} }
+
+##
# @memsave:
#
# Save a portion of guest memory to a file.
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 5c692d0..88e097a 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -385,6 +385,29 @@ Note: CPUs' indexes are obtained with the
'query-cpus' command.
EQMP
{
+ .name = "cpu-add",
+ .args_type = "id:i",
+ .mhandler.cmd_new = qmp_marshal_input_cpu_add,
+ },
+
+SQMP
+cpu-add
+-------
+
+Adds virtual cpu
+
+Arguments:
+
+- "id": cpu id (json-int)
+
+Example:
+
+-> { "execute": "cpu-add", "arguments": {
"id": 2 } }
+<- { "return": {} }
+
+EQMP
+
+ {
.name = "memsave",
.args_type = "val:l,size:i,filename:s,cpu:i?",
.mhandler.cmd_new = qmp_marshal_input_memsave,
diff --git a/qmp.c b/qmp.c
index e3a7f0b..a904568 100644
--- a/qmp.c
+++ b/qmp.c
@@ -23,6 +23,7 @@
#include "hw/qdev.h"
#include "blockdev.h"
#include "qemu/qom-qobject.h"
+#include "hw/boards.h"
NameInfo *qmp_query_name(Error **errp)
{
@@ -107,6 +108,15 @@ void qmp_cpu(int64_t index, Error **errp)
/* Just do nothing */
}
+void qmp_cpu_add(int64_t id, Error **errp)
+{
+ if (current_machine->hot_add_cpu) {
+ current_machine->hot_add_cpu(id, errp);
+ } else {
+ error_setg(errp, "Not supported");
+ }
+}
+
#ifndef CONFIG_VNC
/* If VNC support is enabled, the "true" query-vnc command is
defined in the VNC subsystem */
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Each vcpu needs a call to xc_evtchn_bind_interdomain in QEMU, even those
that are unplug at QEMU initialisation.
Without this patch, any hot-plugged CPU will be "Stuck ??" when Linux
will try to use them.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
xen-all.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen-all.c b/xen-all.c
index daf43b9..15be8ed 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -632,13 +632,13 @@ static ioreq_t *cpu_get_ioreq(XenIOState *state)
}
if (port != -1) {
- for (i = 0; i < smp_cpus; i++) {
+ for (i = 0; i < max_cpus; i++) {
if (state->ioreq_local_port[i] == port) {
break;
}
}
- if (i == smp_cpus) {
+ if (i == max_cpus) {
hw_error("Fatal error while trying to get io event!\n");
}
@@ -1123,10 +1123,10 @@ int xen_hvm_init(void)
hw_error("map buffered IO page returned error %d", errno);
}
- state->ioreq_local_port = g_malloc0(smp_cpus * sizeof (evtchn_port_t));
+ state->ioreq_local_port = g_malloc0(max_cpus * sizeof (evtchn_port_t));
/* FIXME: how about if we overflow the page here? */
- for (i = 0; i < smp_cpus; i++) {
+ for (i = 0; i < max_cpus; i++) {
rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
xen_vcpu_eport(state->shared_page,
i));
if (rc == -1) {
--
Anthony PERARD
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
hw/acpi_piix4.c | 21 +++++++++++++++++++++
hw/pc_piix.c | 1 +
sysemu.h | 2 ++
3 files changed, 24 insertions(+)
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 56d7c2c..059b64f 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -662,6 +662,26 @@ static void piix4_cpu_hotplug_req(PIIX4PMState *s, int64_t
cpu_id,
pm_update_sci(s);
}
+static PIIX4PMState *piix4pm_state;
+void piix4_cpu_hotplug_add(const int64_t cpu_id, Error **errp)
+{
+ CPUStatus *g = &piix4pm_state->gpe_cpu;
+
+ if (cpu_id >= max_cpus) {
+ error_setg(errp, "Unable to add CPU: %" PRIi64
+ ", max allowed: %d", cpu_id, max_cpus - 1);
+ return;
+ }
+ if (g->sts[cpu_id / 8] & (1 << (cpu_id % 8))) {
+ /* Already requested to be hotplug. */
+ error_setg(errp, "Unable to add CPU: %" PRIi64
+ ", it already exists", cpu_id);
+ return;
+ }
+
+ piix4_cpu_hotplug_req(piix4pm_state, cpu_id, PLUG);
+}
+
static void piix4_init_cpu_status(CPUState *cpu, void *data)
{
CPUStatus *g = (CPUStatus *)data;
@@ -697,6 +717,7 @@ static void piix4_acpi_system_hot_add_init(PCIBus *bus,
PIIX4PMState *s)
PIIX4_PROC_LEN);
memory_region_add_subregion(pci_address_space_io(&s->dev),
PIIX4_PROC_BASE, &s->io_cpu);
+ piix4pm_state = s;
}
static void enable_device(PIIX4PMState *s, int slot)
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index aa3e7f4..7e12f5d 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -621,6 +621,7 @@ static QEMUMachine xenfv_machine = {
.init = pc_xen_hvm_init,
.max_cpus = HVM_MAX_VCPUS,
.default_machine_opts = "accel=xen",
+ .hot_add_cpu = piix4_cpu_hotplug_add,
};
#endif
diff --git a/sysemu.h b/sysemu.h
index f5ac664..b71f244 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -183,4 +183,6 @@ char *get_boot_devices_list(uint32_t *size);
bool usb_enabled(bool default_usb);
+void piix4_cpu_hotplug_add(const int64_t cpu_id, Error **errp);
+
#endif
--
Anthony PERARD
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
tools/libxl/libxl_internal.h | 2 ++
tools/libxl/libxl_qmp.c | 21 +++++++++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3ba3a21..3e45b94 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1412,6 +1412,8 @@ _hidden int libxl__qmp_save(libxl__gc *gc, int domid,
const char *filename);
/* Set dirty bitmap logging status */
_hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool
enable);
_hidden int libxl__qmp_insert_cdrom(libxl__gc *gc, int domid, const
libxl_device_disk *disk);
+/* Add a virtual CPU */
+_hidden int libxl__qmp_cpu_add(libxl__gc *gc, int domid, int index);
/* close and free the QMP handler */
_hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
/* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 644d2c0..3d6dec6 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -668,6 +668,18 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
qmp_parameters_common_add(gc, param, name, obj);
}
+static void qmp_parameters_add_integer(libxl__gc *gc,
+ libxl__json_object **param,
+ const char *name, const int i)
+{
+ libxl__json_object *obj;
+
+ obj = libxl__json_object_alloc(gc, JSON_INTEGER);
+ obj->u.i = i;
+
+ qmp_parameters_common_add(gc, param, name, obj);
+}
+
#define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
qmp_parameters_add_string(gc, args, name, \
libxl__sprintf(gc, format, __VA_ARGS__))
@@ -929,6 +941,15 @@ int libxl__qmp_insert_cdrom(libxl__gc *gc, int domid,
}
}
+int libxl__qmp_cpu_add(libxl__gc *gc, int domid, int index)
+{
+ libxl__json_object *args = NULL;
+
+ qmp_parameters_add_integer(gc, &args, "id", index);
+
+ return qmp_run_command(gc, domid, "cpu-add", args, NULL, NULL);
+}
+
int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
const libxl_domain_config *guest_config)
{
--
Anthony PERARD
Anthony PERARD
2013-Jun-17 14:20 UTC
[PATCH v2 2/2] libxl: Use QMP cpu-add to hotplug CPU with qemu-xen.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
tools/libxl/libxl.c | 41 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ee1fa9c..e31b866 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4237,7 +4237,8 @@ int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t
domid,
return 0;
}
-int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *cpumap)
+static int libxl__set_vcpuonline_xenstore(libxl_ctx *ctx, uint32_t domid,
+ libxl_bitmap *cpumap)
{
GC_INIT(ctx);
libxl_dominfo info;
@@ -4268,6 +4269,44 @@ out:
return rc;
}
+static int libxl__set_vcpuonline_qmp(libxl__gc *gc, uint32_t domid,
+ libxl_bitmap *cpumap)
+{
+ libxl_dominfo info;
+ int i, rc = 0;
+
+ if (libxl_domain_info(CTX, &info, domid) < 0) {
+ LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "getting domain info
list");
+ rc = ERROR_FAIL;
+ goto out;
+ }
+ for (i = 0; i <= info.vcpu_max_id; i++) {
+ if (libxl_bitmap_test(cpumap, i)) {
+ rc = libxl__qmp_cpu_add(gc, domid, i);
+ }
+ }
+out:
+ return rc;
+}
+
+int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *cpumap)
+{
+ GC_INIT(ctx);
+ int rc;
+ switch (libxl__device_model_version_running(gc, domid)) {
+ case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+ rc = libxl__set_vcpuonline_xenstore(ctx, domid, cpumap);
+ break;
+ case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+ rc = libxl__set_vcpuonline_qmp(gc, domid, cpumap);
+ break;
+ default:
+ rc = ERROR_INVAL;
+ }
+ GC_FREE;
+ return rc;
+}
+
libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx)
{
libxl_scheduler sched, ret;
--
Anthony PERARD
Anthony PERARD
2013-Jun-17 14:22 UTC
[PATCH v2] xen: Allow CPU to be counted than currently "plugged".
Under Xen, SeaBIOS can count more CPU than there should be. This patch
will allow more CPU to come up instead of going to infinite loop waiting
for the CPU counter to be decremented.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
src/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/smp.c b/src/smp.c
index 3c36f8c..c547746 100644
--- a/src/smp.c
+++ b/src/smp.c
@@ -132,7 +132,7 @@ smp_probe(void)
msleep(10);
} else {
u8 cmos_smp_count = inb_cmos(CMOS_BIOS_SMP_COUNT);
- while (cmos_smp_count + 1 != readl(&CountCPUs))
+ while (cmos_smp_count + 1 > readl(&CountCPUs))
yield();
}
--
Anthony PERARD
Ian Campbell
2013-Jun-17 15:24 UTC
Re: [PATCH v2] xen: Allow CPU to be counted than currently "plugged".
On Mon, 2013-06-17 at 15:22 +0100, Anthony PERARD wrote:> Under Xen, SeaBIOS can count more CPU than there should be. This patch > will allow more CPU to come up instead of going to infinite loop waiting > for the CPU counter to be decremented.Current upstream SeaBIOS has this very different and only runs this loop on Qemu. At a minimum I think we would need to backport: 5dbf173 Only perform SMP setup on QEMU. 897fb11 Consistently use CONFIG_COREBOOT, CONFIG_QEMU, and runningOnXen(). We''ve currently got SeaBIOS 1.7.1 in our tree and these are only in the master branch, but I think backporting is the way to go. Hrm, 897fb11 doesn''t backport cleanly (lots of changes) and without it 5dbf173 doesn''t backport cleanly either. But I think the net affect when running on Xen would be the same as the following, can you try it? diff --git a/src/smp.c b/src/smp.c index 3c36f8c..fb55a6e 100644 --- a/src/smp.c +++ b/src/smp.c @@ -84,6 +84,9 @@ int apic_id_is_present(u8 apic_id) void smp_probe(void) { + if (usingXen()) + return; + ASSERT32FLAT(); u32 eax, ebx, ecx, cpuid_features; cpuid(1, &eax, &ebx, &ecx, &cpuid_features);
On Mon, 2013-06-17 at 15:20 +0100, Anthony PERARD wrote:> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>Acked-by: Ian Campbell <ian.campbell@citrix.com> I suppose I should hold off applying until the qemu side is approved etc. Ian.
On 17/06/13 16:25, Ian Campbell wrote:> On Mon, 2013-06-17 at 15:20 +0100, Anthony PERARD wrote: >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > > Acked-by: Ian Campbell <ian.campbell@citrix.com> > > I suppose I should hold off applying until the qemu side is approved > etc.Well, there will be an error message "explaining" that does not know anything about "cpu-add". So nothing will happen. -- Anthony PERARD
Ian Campbell
2013-Jun-17 15:31 UTC
Re: [PATCH v2 2/2] libxl: Use QMP cpu-add to hotplug CPU with qemu-xen.
On Mon, 2013-06-17 at 15:20 +0100, Anthony PERARD wrote:> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>I''m not sure but I think we might want to do both the xenstore and the qmp thing on qemu-xen for the benefit of PVHVM guests. I''ve added Konrad to the CC.> --- > tools/libxl/libxl.c | 41 ++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 40 insertions(+), 1 deletion(-) > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c > index ee1fa9c..e31b866 100644 > --- a/tools/libxl/libxl.c > +++ b/tools/libxl/libxl.c > @@ -4237,7 +4237,8 @@ int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid, > return 0; > } > > -int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *cpumap) > +static int libxl__set_vcpuonline_xenstore(libxl_ctx *ctx, uint32_t domid, > + libxl_bitmap *cpumap)It''s a bit tedious but really you ought to make this take a gc not a ctx when you internalise it. You can start the function with "libxl__ctx*ctx = libxl__gc_owner(gc)", or s/ctx/CTX/ in the body.> { > GC_INIT(ctx); > libxl_dominfo info; > @@ -4268,6 +4269,44 @@ out: > return rc; > } > > +static int libxl__set_vcpuonline_qmp(libxl__gc *gc, uint32_t domid, > + libxl_bitmap *cpumap) > +{ > + libxl_dominfo info; > + int i, rc = 0; > + > + if (libxl_domain_info(CTX, &info, domid) < 0) { > + LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "getting domain info list");The LOG() macros is useful here.> + rc = ERROR_FAIL; > + goto out; > + } > + for (i = 0; i <= info.vcpu_max_id; i++) { > + if (libxl_bitmap_test(cpumap, i)) { > + rc = libxl__qmp_cpu_add(gc, domid, i); > + } > + } > +out: > + return rc; > +}
On Mon, 2013-06-17 at 16:28 +0100, Anthony PERARD wrote:> On 17/06/13 16:25, Ian Campbell wrote: > > On Mon, 2013-06-17 at 15:20 +0100, Anthony PERARD wrote: > >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > > > > Acked-by: Ian Campbell <ian.campbell@citrix.com> > > > > I suppose I should hold off applying until the qemu side is approved > > etc. > > Well, there will be an error message "explaining" that does not know > anything about "cpu-add". So nothing will happen.I meant more from the point of view of agreeing both sides of the protocol before proceeding. Ian.
Anthony PERARD
2013-Jun-17 15:44 UTC
Re: [PATCH v2] xen: Allow CPU to be counted than currently "plugged".
On 17/06/13 16:24, Ian Campbell wrote:> On Mon, 2013-06-17 at 15:22 +0100, Anthony PERARD wrote: >> Under Xen, SeaBIOS can count more CPU than there should be. This patch >> will allow more CPU to come up instead of going to infinite loop waiting >> for the CPU counter to be decremented. > > Current upstream SeaBIOS has this very different and only runs this loop > on Qemu. > > At a minimum I think we would need to backport: > 5dbf173 Only perform SMP setup on QEMU. > 897fb11 Consistently use CONFIG_COREBOOT, CONFIG_QEMU, and runningOnXen(). > > We''ve currently got SeaBIOS 1.7.1 in our tree and these are only in the > master branch, but I think backporting is the way to go. > > Hrm, 897fb11 doesn''t backport cleanly (lots of changes) and without it > 5dbf173 doesn''t backport cleanly either. But I think the net affect when > running on Xen would be the same as the following, can you try it? > > diff --git a/src/smp.c b/src/smp.c > index 3c36f8c..fb55a6e 100644 > --- a/src/smp.c > +++ b/src/smp.c > @@ -84,6 +84,9 @@ int apic_id_is_present(u8 apic_id) > void > smp_probe(void) > { > + if (usingXen()) > + return; > + > ASSERT32FLAT(); > u32 eax, ebx, ecx, cpuid_features; > cpuid(1, &eax, &ebx, &ecx, &cpuid_features); > >This patch definitely works. It was one of my two choices. I though the other approch was better because of mtrr_setup() called before this function, and some mtrr stuff in this function, but I did not realize that mtrr_setup is not doing anything under Xen. So this patch (no smp_probe) is better. -- Anthony PERARD
Anthony PERARD
2013-Jun-17 15:50 UTC
Re: [PATCH v2 2/2] libxl: Use QMP cpu-add to hotplug CPU with qemu-xen.
On 17/06/13 16:31, Ian Campbell wrote:> On Mon, 2013-06-17 at 15:20 +0100, Anthony PERARD wrote: >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > > I''m not sure but I think we might want to do both the xenstore and the > qmp thing on qemu-xen for the benefit of PVHVM guests. I''ve added Konrad > to the CC.ok, that should be not to complicated to do, if necessary.>> --- >> tools/libxl/libxl.c | 41 ++++++++++++++++++++++++++++++++++++++++- >> 1 file changed, 40 insertions(+), 1 deletion(-) >> >> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c >> index ee1fa9c..e31b866 100644 >> --- a/tools/libxl/libxl.c >> +++ b/tools/libxl/libxl.c >> @@ -4237,7 +4237,8 @@ int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid, >> return 0; >> } >> >> -int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *cpumap) >> +static int libxl__set_vcpuonline_xenstore(libxl_ctx *ctx, uint32_t domid, >> + libxl_bitmap *cpumap) > > It''s a bit tedious but really you ought to make this take a gc not a ctx > when you internalise it. You can start the function with "libxl__ctx*ctx > = libxl__gc_owner(gc)", or s/ctx/CTX/ in the body.OK, will change this.>> { >> GC_INIT(ctx); >> libxl_dominfo info; >> @@ -4268,6 +4269,44 @@ out: >> return rc; >> } >> >> +static int libxl__set_vcpuonline_qmp(libxl__gc *gc, uint32_t domid, >> + libxl_bitmap *cpumap) >> +{ >> + libxl_dominfo info; >> + int i, rc = 0; >> + >> + if (libxl_domain_info(CTX, &info, domid) < 0) { >> + LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "getting domain info list"); > > The LOG() macros is useful here.will change this.>> + rc = ERROR_FAIL; >> + goto out; >> + } >> + for (i = 0; i <= info.vcpu_max_id; i++) { >> + if (libxl_bitmap_test(cpumap, i)) { >> + rc = libxl__qmp_cpu_add(gc, domid, i); >> + } >> + } >> +out: >> + return rc; >> +} > >-- Anthony PERARD
Stefano Stabellini
2013-Jun-20 11:12 UTC
Re: [PATCH v2 2/2] libxl: Use QMP cpu-add to hotplug CPU with qemu-xen.
On Mon, 17 Jun 2013, Anthony PERARD wrote:> On 17/06/13 16:31, Ian Campbell wrote: > > On Mon, 2013-06-17 at 15:20 +0100, Anthony PERARD wrote: > >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > > > > I''m not sure but I think we might want to do both the xenstore and the > > qmp thing on qemu-xen for the benefit of PVHVM guests. I''ve added Konrad > > to the CC. > > ok, that should be not to complicated to do, if necessary.PV on HVM guests use the emulated path for cpu hotplug.
On Mon, 17 Jun 2013, Anthony PERARD wrote:> Each vcpu needs a call to xc_evtchn_bind_interdomain in QEMU, even those > that are unplug at QEMU initialisation. > > Without this patch, any hot-plugged CPU will be "Stuck ??" when Linux > will try to use them. > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>> xen-all.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/xen-all.c b/xen-all.c > index daf43b9..15be8ed 100644 > --- a/xen-all.c > +++ b/xen-all.c > @@ -632,13 +632,13 @@ static ioreq_t *cpu_get_ioreq(XenIOState *state) > } > > if (port != -1) { > - for (i = 0; i < smp_cpus; i++) { > + for (i = 0; i < max_cpus; i++) { > if (state->ioreq_local_port[i] == port) { > break; > } > } > > - if (i == smp_cpus) { > + if (i == max_cpus) { > hw_error("Fatal error while trying to get io event!\n"); > } > > @@ -1123,10 +1123,10 @@ int xen_hvm_init(void) > hw_error("map buffered IO page returned error %d", errno); > } > > - state->ioreq_local_port = g_malloc0(smp_cpus * sizeof (evtchn_port_t)); > + state->ioreq_local_port = g_malloc0(max_cpus * sizeof (evtchn_port_t)); > > /* FIXME: how about if we overflow the page here? */ > - for (i = 0; i < smp_cpus; i++) { > + for (i = 0; i < max_cpus; i++) { > rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid, > xen_vcpu_eport(state->shared_page, i)); > if (rc == -1) { > -- > Anthony PERARD >
Can''t we just call pc_new_cpu and cpu_x86_create like upstream QEMU does? Are there any reasons why we can''t introduce the same cpu_added_notifier that is upstream? On Mon, 17 Jun 2013, Anthony PERARD wrote:> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > --- > hw/acpi_piix4.c | 21 +++++++++++++++++++++ > hw/pc_piix.c | 1 + > sysemu.h | 2 ++ > 3 files changed, 24 insertions(+) > > diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c > index 56d7c2c..059b64f 100644 > --- a/hw/acpi_piix4.c > +++ b/hw/acpi_piix4.c > @@ -662,6 +662,26 @@ static void piix4_cpu_hotplug_req(PIIX4PMState *s, int64_t cpu_id, > pm_update_sci(s); > } > > +static PIIX4PMState *piix4pm_state; > +void piix4_cpu_hotplug_add(const int64_t cpu_id, Error **errp) > +{ > + CPUStatus *g = &piix4pm_state->gpe_cpu; > + > + if (cpu_id >= max_cpus) { > + error_setg(errp, "Unable to add CPU: %" PRIi64 > + ", max allowed: %d", cpu_id, max_cpus - 1); > + return; > + } > + if (g->sts[cpu_id / 8] & (1 << (cpu_id % 8))) { > + /* Already requested to be hotplug. */ > + error_setg(errp, "Unable to add CPU: %" PRIi64 > + ", it already exists", cpu_id); > + return; > + } > + > + piix4_cpu_hotplug_req(piix4pm_state, cpu_id, PLUG); > +} > + > static void piix4_init_cpu_status(CPUState *cpu, void *data) > { > CPUStatus *g = (CPUStatus *)data; > @@ -697,6 +717,7 @@ static void piix4_acpi_system_hot_add_init(PCIBus *bus, PIIX4PMState *s) > PIIX4_PROC_LEN); > memory_region_add_subregion(pci_address_space_io(&s->dev), > PIIX4_PROC_BASE, &s->io_cpu); > + piix4pm_state = s; > } > > static void enable_device(PIIX4PMState *s, int slot) > diff --git a/hw/pc_piix.c b/hw/pc_piix.c > index aa3e7f4..7e12f5d 100644 > --- a/hw/pc_piix.c > +++ b/hw/pc_piix.c > @@ -621,6 +621,7 @@ static QEMUMachine xenfv_machine = { > .init = pc_xen_hvm_init, > .max_cpus = HVM_MAX_VCPUS, > .default_machine_opts = "accel=xen", > + .hot_add_cpu = piix4_cpu_hotplug_add, > }; > #endif > > diff --git a/sysemu.h b/sysemu.h > index f5ac664..b71f244 100644 > --- a/sysemu.h > +++ b/sysemu.h > @@ -183,4 +183,6 @@ char *get_boot_devices_list(uint32_t *size); > > bool usb_enabled(bool default_usb); > > +void piix4_cpu_hotplug_add(const int64_t cpu_id, Error **errp); > + > #endif > -- > Anthony PERARD >
On 20/06/13 12:21, Stefano Stabellini wrote:> Can''t we just call pc_new_cpu and cpu_x86_create like upstream QEMU > does? > Are there any reasons why we can''t introduce the same > cpu_added_notifier that is upstream?Yes, in our current version of qemu-xen, a CPU can not be hotplug. When pc_new_cpu is called, there is a check to see if this object (cpu) can be hotplug to the machine. The original patch series was introducing that, I think. So it would require few more patches from QEMU which would made the backport more complicated. And the notifier depend on the creation of new object cpu. -- Anthony PERARD
On Mon, 17 Jun 2013, Anthony PERARD wrote:> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > --- > hw/acpi_piix4.c | 21 +++++++++++++++++++++ > hw/pc_piix.c | 1 + > sysemu.h | 2 ++ > 3 files changed, 24 insertions(+) > > diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c > index 56d7c2c..059b64f 100644 > --- a/hw/acpi_piix4.c > +++ b/hw/acpi_piix4.c > @@ -662,6 +662,26 @@ static void piix4_cpu_hotplug_req(PIIX4PMState *s, int64_t cpu_id, > pm_update_sci(s); > } > > +static PIIX4PMState *piix4pm_state;I really dislike this static variable. Isn''t there a way to retrieve the PIIX4PMState from the cpu_id?> +void piix4_cpu_hotplug_add(const int64_t cpu_id, Error **errp) > +{ > + CPUStatus *g = &piix4pm_state->gpe_cpu; > + > + if (cpu_id >= max_cpus) { > + error_setg(errp, "Unable to add CPU: %" PRIi64 > + ", max allowed: %d", cpu_id, max_cpus - 1); > + return; > + } > + if (g->sts[cpu_id / 8] & (1 << (cpu_id % 8))) { > + /* Already requested to be hotplug. */ > + error_setg(errp, "Unable to add CPU: %" PRIi64 > + ", it already exists", cpu_id); > + return; > + } > + > + piix4_cpu_hotplug_req(piix4pm_state, cpu_id, PLUG); > +} > + > static void piix4_init_cpu_status(CPUState *cpu, void *data) > { > CPUStatus *g = (CPUStatus *)data; > @@ -697,6 +717,7 @@ static void piix4_acpi_system_hot_add_init(PCIBus *bus, PIIX4PMState *s) > PIIX4_PROC_LEN); > memory_region_add_subregion(pci_address_space_io(&s->dev), > PIIX4_PROC_BASE, &s->io_cpu); > + piix4pm_state = s; > } > > static void enable_device(PIIX4PMState *s, int slot) > diff --git a/hw/pc_piix.c b/hw/pc_piix.c > index aa3e7f4..7e12f5d 100644 > --- a/hw/pc_piix.c > +++ b/hw/pc_piix.c > @@ -621,6 +621,7 @@ static QEMUMachine xenfv_machine = { > .init = pc_xen_hvm_init, > .max_cpus = HVM_MAX_VCPUS, > .default_machine_opts = "accel=xen", > + .hot_add_cpu = piix4_cpu_hotplug_add, > }; > #endif > > diff --git a/sysemu.h b/sysemu.h > index f5ac664..b71f244 100644 > --- a/sysemu.h > +++ b/sysemu.h > @@ -183,4 +183,6 @@ char *get_boot_devices_list(uint32_t *size); > > bool usb_enabled(bool default_usb); > > +void piix4_cpu_hotplug_add(const int64_t cpu_id, Error **errp); > + > #endif > -- > Anthony PERARD >
On 20/06/13 14:40, Stefano Stabellini wrote:>> > diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c >> > index 56d7c2c..059b64f 100644 >> > --- a/hw/acpi_piix4.c >> > +++ b/hw/acpi_piix4.c >> > @@ -662,6 +662,26 @@ static void piix4_cpu_hotplug_req(PIIX4PMState *s, int64_t cpu_id, >> > pm_update_sci(s); >> > } >> > >> > +static PIIX4PMState *piix4pm_state; > I really dislike this static variable. Isn''t there a way to retrieve the > PIIX4PMState from the cpu_id?There is currently no other way to get the state from. The way it''s done upsteam is by introducing a new notifier for added cpus, but it just another static variable hidden somewhere else. The patch introducing the new notifier could be backported but not as is, as it would require other change on the CPU object (as explain in an other mail in this thread). So this static global variable seams to me the simple thing to do for the release instead of backporting more and more patches. -- Anthony PERARD
Stefano Stabellini
2013-Jun-24 16:57 UTC
Re: [PATCH v2 0/7] CPU hotplug for qemu-xen for 4.3.
On Mon, 17 Jun 2013, Anthony PERARD wrote:> Hi all, > > This series back-port recently added QEMU patches to our qemu-xen. The > interface between the guest and QEMU is the same as with qemu-traditional. Only > the interface between libxl and qemu change, instead of xenstore we are using > QMP to hotplug vcpus. > > Three more patches will follow this series. > - two for libxl which implement the QMP command cpu-add. > - one for SeaBIOS which workaround a bug. > > When using adding vcpus with this series, libxl will report many "error". This > is because libxl call the QMP command ''cpu-add'' for every plugged vcpus, even > those that have been plugged before. There is currently no way to list cpus > that are plugged by QEMU. Also, the ways errors are handle by libxl_qmp those > not help yet to suppress this error printing. > > Unplug of vcpu is not supported by the series. > > Change since the first set: > - back-port of QEMU patches instead of forth-port from qemu-traditional > - added a SeaBIOS patch > > Regards,George, the patches are OK to go in qemu-xen as far as I am concerned. Should I go ahead and apply them?
Stefano Stabellini
2013-Jun-24 17:21 UTC
Re: [PATCH v2 0/7] CPU hotplug for qemu-xen for 4.3.
On Mon, 24 Jun 2013, Stefano Stabellini wrote:> On Mon, 17 Jun 2013, Anthony PERARD wrote: > > Hi all, > > > > This series back-port recently added QEMU patches to our qemu-xen. The > > interface between the guest and QEMU is the same as with qemu-traditional. Only > > the interface between libxl and qemu change, instead of xenstore we are using > > QMP to hotplug vcpus. > > > > Three more patches will follow this series. > > - two for libxl which implement the QMP command cpu-add. > > - one for SeaBIOS which workaround a bug. > > > > When using adding vcpus with this series, libxl will report many "error". This > > is because libxl call the QMP command ''cpu-add'' for every plugged vcpus, even > > those that have been plugged before. There is currently no way to list cpus > > that are plugged by QEMU. Also, the ways errors are handle by libxl_qmp those > > not help yet to suppress this error printing. > > > > Unplug of vcpu is not supported by the series. > > > > Change since the first set: > > - back-port of QEMU patches instead of forth-port from qemu-traditional > > - added a SeaBIOS patch > > > > Regards, > > George, > the patches are OK to go in qemu-xen as far as I am concerned. > Should I go ahead and apply them? >BTW Anthony, do you have a git branch based on qemu-xen that I can pull?
On 24/06/13 18:21, Stefano Stabellini wrote:> On Mon, 24 Jun 2013, Stefano Stabellini wrote: >> On Mon, 17 Jun 2013, Anthony PERARD wrote: >>> Hi all, >>> >>> This series back-port recently added QEMU patches to our qemu-xen. The >>> interface between the guest and QEMU is the same as with qemu-traditional. Only >>> the interface between libxl and qemu change, instead of xenstore we are using >>> QMP to hotplug vcpus. >>> >>> Three more patches will follow this series. >>> - two for libxl which implement the QMP command cpu-add. >>> - one for SeaBIOS which workaround a bug. >>> >>> When using adding vcpus with this series, libxl will report many "error". This >>> is because libxl call the QMP command ''cpu-add'' for every plugged vcpus, even >>> those that have been plugged before. There is currently no way to list cpus >>> that are plugged by QEMU. Also, the ways errors are handle by libxl_qmp those >>> not help yet to suppress this error printing. >>> >>> Unplug of vcpu is not supported by the series. >>> >>> Change since the first set: >>> - back-port of QEMU patches instead of forth-port from qemu-traditional >>> - added a SeaBIOS patch >>> >>> Regards, >> >> George, >> the patches are OK to go in qemu-xen as far as I am concerned. >> Should I go ahead and apply them? >> > > BTW Anthony, do you have a git branch based on qemu-xen that I can pull?git://xenbits.xen.org/people/aperard/qemu-dm.git branch cpu-hotplug-port-v2 -- Anthony PERARD
On 06/24/2013 05:57 PM, Stefano Stabellini wrote:> On Mon, 17 Jun 2013, Anthony PERARD wrote: >> Hi all, >> >> This series back-port recently added QEMU patches to our qemu-xen. The >> interface between the guest and QEMU is the same as with qemu-traditional. Only >> the interface between libxl and qemu change, instead of xenstore we are using >> QMP to hotplug vcpus. >> >> Three more patches will follow this series. >> - two for libxl which implement the QMP command cpu-add. >> - one for SeaBIOS which workaround a bug. >> >> When using adding vcpus with this series, libxl will report many "error". This >> is because libxl call the QMP command ''cpu-add'' for every plugged vcpus, even >> those that have been plugged before. There is currently no way to list cpus >> that are plugged by QEMU. Also, the ways errors are handle by libxl_qmp those >> not help yet to suppress this error printing. >> >> Unplug of vcpu is not supported by the series. >> >> Change since the first set: >> - back-port of QEMU patches instead of forth-port from qemu-traditional >> - added a SeaBIOS patch >> >> Regards, > > George, > the patches are OK to go in qemu-xen as far as I am concerned. > Should I go ahead and apply them? >Yes, please do. -George
Stefano Stabellini
2013-Jun-25 11:40 UTC
Re: [PATCH v2 0/7] CPU hotplug for qemu-xen for 4.3.
On Tue, 25 Jun 2013, George Dunlap wrote:> On 06/24/2013 05:57 PM, Stefano Stabellini wrote: > > On Mon, 17 Jun 2013, Anthony PERARD wrote: > > > Hi all, > > > > > > This series back-port recently added QEMU patches to our qemu-xen. The > > > interface between the guest and QEMU is the same as with qemu-traditional. > > > Only > > > the interface between libxl and qemu change, instead of xenstore we are > > > using > > > QMP to hotplug vcpus. > > > > > > Three more patches will follow this series. > > > - two for libxl which implement the QMP command cpu-add. > > > - one for SeaBIOS which workaround a bug. > > > > > > When using adding vcpus with this series, libxl will report many "error". > > > This > > > is because libxl call the QMP command ''cpu-add'' for every plugged vcpus, > > > even > > > those that have been plugged before. There is currently no way to list > > > cpus > > > that are plugged by QEMU. Also, the ways errors are handle by libxl_qmp > > > those > > > not help yet to suppress this error printing. > > > > > > Unplug of vcpu is not supported by the series. > > > > > > Change since the first set: > > > - back-port of QEMU patches instead of forth-port from qemu-traditional > > > - added a SeaBIOS patch > > > > > > Regards, > > > > George, > > the patches are OK to go in qemu-xen as far as I am concerned. > > Should I go ahead and apply them? > > > > Yes, please do.done