On 11/06/2017 11:08 AM, Andrea Bolognani wrote:
Most of the time it's okay to leave this up to negotiation
between
the guest and the host, but in some situations it can be useful to
manually decide the behavior, especially to enforce its availability.
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1308743
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
docs/schemas/domaincommon.rng | 15 ++++++++
src/conf/domain_conf.c | 46 +++++++++++++++++++++++-
src/conf/domain_conf.h | 12 +++++++
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 8 +++++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 20 +++++++++++
src/qemu/qemu_domain.c | 8 +++++
tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 1 +
9 files changed, 111 insertions(+), 1 deletion(-)
[...]
diff --git a/src/qemu/qemu_capabilities.c
b/src/qemu/qemu_capabilities.c
index 7cb091056..1badadbc2 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -443,6 +443,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
/* 270 */
"vxhs",
"virtio-blk.num-queues",
+ "machine.pseries.resize-hpt",
);
@@ -4776,6 +4777,13 @@ virQEMUCapsInitQMPMonitor(virQEMUCapsPtr qemuCaps,
if (qemuCaps->version >= 2006000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACHINE_KERNEL_IRQCHIP_SPLIT);
+ /* HPT resizing is supported since QEMU 2.10 on ppc64; unfortunately
+ * there's no sane way to probe for it */
+ if (qemuCaps->version >= 2010000 &&
+ ARCH_IS_PPC64(qemuCaps->arch)) {
This check differs slightly from qemuDomainDefVerifyFeatures
+ virQEMUCapsSet(qemuCaps,
QEMU_CAPS_MACHINE_PSERIES_RESIZE_HPT);
+ }
+
if (virQEMUCapsProbeQMPCommands(qemuCaps, mon) < 0)
goto cleanup;
[...]
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 8708b79ed..e8868a34a 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -7526,6 +7526,26 @@ qemuBuildMachineCommandLine(virCommandPtr cmd,
}
}
+ if (def->features[VIR_DOMAIN_FEATURE_HPT] == VIR_TRISTATE_SWITCH_ON) {
+ const char *str;
+
+ if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_MACHINE_PSERIES_RESIZE_HPT)) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("HTP resizing is not supported by this "
+ "QEMU binary"));
+ goto cleanup;
+ }
+
+ str = virDomainHPTResizingTypeToString(def->hpt_resizing);
+ if (!str) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("Invalid setting for HPT resizing"));
+ goto cleanup;
+ }
+
+ virBufferAsprintf(&buf, ",resize-hpt=%s", str);
This one only cares about the capability...
+ }
+
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_BOOTINDEX) &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_LOADPARM))
qemuAppendLoadparmMachineParm(&buf, def);
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index b248a3ddc..60e6da327 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -3142,6 +3142,14 @@ qemuDomainDefVerifyFeatures(const virDomainDef *def)
return -1;
}
+ if (def->features[VIR_DOMAIN_FEATURE_HPT] == VIR_TRISTATE_SWITCH_ON &&
+ !qemuDomainIsPSeries(def)) {
But this one adds the def->machine.os check... I know it's post parse
so it should thus cause failure before building the command line occurs,
so the question is should capability use "&& qemuDomainIsPSeries"?
Your
call...
Reviewed-by: John Ferlan <jferlan(a)redhat.com>
John
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ "%s",
+ _("HPT tuning is only supported for pSeries guests"));
+ return -1;
+ }
+
return 0;
}
[...]