QEMU 2.7 and newer don't allow guests to start unless the initial
vCPUs count is a multiple of the vCPU hotplug granularity, so
validate it and report an error if needed.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1283700
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
---
src/qemu/qemu_domain.c | 41 ++++++++++++++++++++++
tests/qemuxml2argvdata/cpu-hotplug-granularity.xml | 18 ++++++++++
tests/qemuxml2argvtest.c | 3 ++
3 files changed, 62 insertions(+)
create mode 100644 tests/qemuxml2argvdata/cpu-hotplug-granularity.xml
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index e93333669..632f330f7 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -3289,6 +3289,36 @@ qemuDomainDefValidateVideo(const virDomainDef *def)
}
+/**
+ * qemuDomainDefGetVcpuHotplugGranularity:
+ * @def: domain definition
+ * @granularity: return location for vCPU hotplug granularity
+ *
+ * With QEMU 2.7 and newer, vCPUs can only be hotplugged @granularity at
+ * a time; because of that, QEMU will not allow guests to start unless the
+ * initial number of vCPUs is a multiple of @granularity.
+ *
+ * Returns 0 on success, 1 if topology is not configured and -1 on error.
+ */
+static int
+qemuDomainDefGetVcpuHotplugGranularity(const virDomainDef *def,
+ unsigned int *granularity)
+{
+ if (!granularity)
+ return -1;
+
+ if (!def->cpu || def->cpu->sockets == 0)
+ return 1;
+
+ if (qemuDomainIsPSeries(def))
+ *granularity = def->cpu->threads;
+ else
+ *granularity = 1;
+
+ return 0;
+}
+
+
#define QEMU_MAX_VCPUS_WITHOUT_EIM 255
@@ -3363,6 +3393,7 @@ qemuDomainDefValidate(const virDomainDef *def,
* CPU topology. Verify known constraints are respected */
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS)) {
unsigned int topologycpus;
+ unsigned int granularity;
/* Max vCPU count and overall vCPU topology must agree */
if (virDomainDefGetVcpusTopology(def, &topologycpus) == 0 &&
@@ -3371,6 +3402,16 @@ qemuDomainDefValidate(const virDomainDef *def,
_("CPU topology doesn't match maximum vcpu count"));
goto cleanup;
}
+
+ /* vCPU hotplug granularity must be respected */
+ if (qemuDomainDefGetVcpuHotplugGranularity(def, &granularity) == 0 &&
+ (virDomainDefGetVcpus(def) % granularity) != 0) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("vCPUs count must be a multiple of the vCPU "
+ "hotplug granularity (%u)"),
+ granularity);
+ goto cleanup;
+ }
}
if (ARCH_IS_X86(def->os.arch) &&
diff --git a/tests/qemuxml2argvdata/cpu-hotplug-granularity.xml b/tests/qemuxml2argvdata/cpu-hotplug-granularity.xml
new file mode 100644
index 000000000..a94f41e46
--- /dev/null
+++ b/tests/qemuxml2argvdata/cpu-hotplug-granularity.xml
@@ -0,0 +1,18 @@
+<domain type='qemu'>
+ <name>guest</name>
+ <uuid>1ccfd97d-5eb4-478a-bbe6-88d254c16db7</uuid>
+ <memory unit='KiB'>524288</memory>
+ <vcpu placement='static' current='2'>8</vcpu>
+ <os>
+ <type arch='ppc64' machine='pseries'>hvm</type>
+ </os>
+ <cpu>
+ <topology sockets='1' cores='2' threads='4'/>
+ </cpu>
+ <devices>
+ <emulator>/usr/bin/qemu-system-ppc64</emulator>
+ <controller type='pci' model='pci-root'/>
+ <controller type='usb' model='none'/>
+ <memballoon model='none'/>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index ca24e0bbb..10ab8d787 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -2900,6 +2900,9 @@ mymain(void)
QEMU_CAPS_DEVICE_INTEL_IOMMU);
DO_TEST("cpu-hotplug-startup", QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS);
+ DO_TEST_PARSE_ERROR("cpu-hotplug-granularity",
+ QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS);
+
DO_TEST("virtio-options", QEMU_CAPS_VIRTIO_SCSI, QEMU_CAPS_VIRTIO_KEYBOARD,
QEMU_CAPS_VIRTIO_MOUSE, QEMU_CAPS_VIRTIO_TABLET,
QEMU_CAPS_VIRTIO_INPUT_HOST,
--
2.14.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Dec 14, 2017 at 17:29:51 +0100, Andrea Bolognani wrote: > QEMU 2.7 and newer don't allow guests to start unless the initial > vCPUs count is a multiple of the vCPU hotplug granularity, so > validate it and report an error if needed. > > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1283700 > > Signed-off-by: Andrea Bolognani <abologna@redhat.com> > --- > src/qemu/qemu_domain.c | 41 ++++++++++++++++++++++ > tests/qemuxml2argvdata/cpu-hotplug-granularity.xml | 18 ++++++++++ > tests/qemuxml2argvtest.c | 3 ++ > 3 files changed, 62 insertions(+) > create mode 100644 tests/qemuxml2argvdata/cpu-hotplug-granularity.xml > > diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c > index e93333669..632f330f7 100644 > --- a/src/qemu/qemu_domain.c > +++ b/src/qemu/qemu_domain.c > @@ -3289,6 +3289,36 @@ qemuDomainDefValidateVideo(const virDomainDef *def) > } > > > +/** > + * qemuDomainDefGetVcpuHotplugGranularity: > + * @def: domain definition > + * @granularity: return location for vCPU hotplug granularity > + * > + * With QEMU 2.7 and newer, vCPUs can only be hotplugged @granularity at > + * a time; because of that, QEMU will not allow guests to start unless the > + * initial number of vCPUs is a multiple of @granularity. > + * > + * Returns 0 on success, 1 if topology is not configured and -1 on error. > + */ > +static int > +qemuDomainDefGetVcpuHotplugGranularity(const virDomainDef *def, > + unsigned int *granularity) > +{ > + if (!granularity) > + return -1; Why? > + > + if (!def->cpu || def->cpu->sockets == 0) > + return 1; I think we assume '1' as threads here if it's not specified. > + > + if (qemuDomainIsPSeries(def)) > + *granularity = def->cpu->threads; > + else > + *granularity = 1; Why not just return the granularity rather than this weirdness? > + > + return 0; > +} > + > + -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, 2017-12-15 at 13:22 +0100, Peter Krempa wrote: > > + > > + if (!def->cpu || def->cpu->sockets == 0) > > + return 1; > > I think we assume '1' as threads here if it's not specified. Okay. > > + > > + if (qemuDomainIsPSeries(def)) > > + *granularity = def->cpu->threads; > > + else > > + *granularity = 1; > > Why not just return the granularity rather than this weirdness? Sure, I can do that. Does the rest of the patch look reasonable, or do you want to point out anything else before I respin? -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2025 Red Hat, Inc.