On Thu, Sep 26, 2013 at 10:50:16AM +0200, Ján Tomko wrote:
Since qemu-kvm 1.1 [1] (since 1.3. in upstream QEMU [2])
'-no-kvm-pit-reinjection' has been deprecated.
Use -global kvm-pit.lost_tick_policy=discard instead.
https://bugzilla.redhat.com/show_bug.cgi?id=978719
[1]
http://git.kernel.org/cgit/virt/kvm/qemu-kvm.git/commit/?id=4e4fa39
[2]
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=c21fb4f
---
v3: use -global instead of trying to add another -device
re:
https://www.redhat.com/archives/libvir-list/2013-July/msg00833.html
Unsetting the QEMU_CAPS_NO_KVM_PIT capability for QEMU >1.2 seems to work
okay with libvirtd upgrades.
v2:
https://www.redhat.com/archives/libvir-list/2013-July/msg00821.html
v1:
https://www.redhat.com/archives/libvir-list/2013-July/msg00045.html
src/qemu/qemu_capabilities.c | 5 ++--
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 8 ++++--
.../qemuxml2argv-kvm-pit-delay.args | 5 ++++
.../qemuxml2argv-kvm-pit-delay.xml | 29 ++++++++++++++++++++++
.../qemuxml2argv-kvm-pit-device.args | 5 ++++
.../qemuxml2argv-kvm-pit-device.xml | 29 ++++++++++++++++++++++
tests/qemuxml2argvtest.c | 4 +++
8 files changed, 82 insertions(+), 4 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-delay.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-delay.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-device.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-device.xml
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index dc8f0be..06b71b5 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -242,6 +242,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
"usb-storage.removable",
"virtio-mmio",
"ich9-intel-hda",
+ "kvm-pit",
);
struct _virQEMUCaps {
@@ -1393,6 +1394,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
{ "usb-storage", QEMU_CAPS_DEVICE_USB_STORAGE },
{ "virtio-mmio", QEMU_CAPS_DEVICE_VIRTIO_MMIO },
{ "ich9-intel-hda", QEMU_CAPS_DEVICE_ICH9_INTEL_HDA },
+ { "kvm-pit", QEMU_CAPS_DEVICE_KVM_PIT },
};
Cleaner way would be (IMHO):
static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsKvmPit[] = {
{ "lost_tick_policy", QEMU_CAPS_KVM_PIT_TICK_POLICY },
};
(or similar) and then adding into virQEMUCapsObjectProps[]:
{ "kvm-pit", virQEMUCapsObjectPropsKvmPit,
ARRAY_CARDINALITY(virQEMUCapsObjectPropsKvmPit) }
static struct virQEMUCapsStringFlags
virQEMUCapsObjectPropsVirtioBlk[] = {
@@ -2477,13 +2479,12 @@ virQEMUCapsInitArchQMPBasic(virQEMUCapsPtr qemuCaps,
/*
* Currently only x86_64 and i686 support PCI-multibus,
- * -no-acpi and -no-kvm-pit-reinjection.
+ * -no-acpi
*/
if (qemuCaps->arch == VIR_ARCH_X86_64 ||
qemuCaps->arch == VIR_ARCH_I686) {
virQEMUCapsSet(qemuCaps, QEMU_CAPS_PCI_MULTIBUS);
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_ACPI);
- virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_KVM_PIT);
}
Sorry to dissapoint you in v3, but I must say, I still agree with
Eric. Since that flag is just 'deprecated', it doesn't mean that it
is not recognized. And thanks to the fact that you have a possibility
to check whether the newer 'kvm-pit.lost_tick_policy' is supported,
you can safely choose all three states even if there is a qemu with
QMP on x86_64 without 'kvm-pit.lost_tick_policy' and it will still
work correctly then.
I'd keep the fallback until it is recognized, so it can be used even
if there is no other (non-deprecated) option.
Martin