2:31 a.m.
QEMU added the machine types for the 5.1 release so let's update them.
Other notable changes are 'cpu-throttle-tailslow' migration property,
'zlib' compression for qcow2 images and absrtact socket support.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
As usual, I'll be refreshing this until the release so that we always
have fresh capabilities to prevent any surprises with deprecation and
big updates.
.../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 2 +-
.../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 2 +-
tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 2 +-
.../caps_5.1.0.x86_64.replies | 357 +++++++++++-------
.../caps_5.1.0.x86_64.xml | 14 +-
5 files changed, 237 insertions(+), 140 deletions(-)
diff --git a/tests/domaincapsdata/qemu_5.1.0-q35.x86_64.xml
b/tests/domaincapsdata/qemu_5.1.0-q35.x86_64.xml
index e152f7dec5..996461fb0f 100644
--- a/tests/domaincapsdata/qemu_5.1.0-q35.x86_64.xml
+++ b/tests/domaincapsdata/qemu_5.1.0-q35.x86_64.xml
@@ -1,7 +1,7 @@
<domainCapabilities>
<path>/usr/bin/qemu-system-x86_64</path>
<domain>kvm</domain>
- <machine>pc-q35-5.0</machine>
+ <machine>pc-q35-5.1</machine>
<arch>x86_64</arch>
<vcpu max='288'/>
<iothreads supported='yes'/>
diff --git a/tests/domaincapsdata/qemu_5.1.0-tcg.x86_64.xml
b/tests/domaincapsdata/qemu_5.1.0-tcg.x86_64.xml
index a0eeed7c2d..e4801b2750 100644
--- a/tests/domaincapsdata/qemu_5.1.0-tcg.x86_64.xml
+++ b/tests/domaincapsdata/qemu_5.1.0-tcg.x86_64.xml
@@ -1,7 +1,7 @@
<domainCapabilities>
<path>/usr/bin/qemu-system-x86_64</path>
<domain>qemu</domain>
- <machine>pc-i440fx-5.0</machine>
+ <machine>pc-i440fx-5.1</machine>
<arch>x86_64</arch>
<vcpu max='255'/>
<iothreads supported='yes'/>
diff --git a/tests/domaincapsdata/qemu_5.1.0.x86_64.xml
b/tests/domaincapsdata/qemu_5.1.0.x86_64.xml
index bc842730a0..e95fcec8bc 100644
--- a/tests/domaincapsdata/qemu_5.1.0.x86_64.xml
+++ b/tests/domaincapsdata/qemu_5.1.0.x86_64.xml
@@ -1,7 +1,7 @@
<domainCapabilities>
<path>/usr/bin/qemu-system-x86_64</path>
<domain>kvm</domain>
- <machine>pc-i440fx-5.0</machine>
+ <machine>pc-i440fx-5.1</machine>
<arch>x86_64</arch>
<vcpu max='255'/>
<iothreads supported='yes'/>
diff --git a/tests/qemucapabilitiesdata/caps_5.1.0.x86_64.replies
b/tests/qemucapabilitiesdata/caps_5.1.0.x86_64.replies
index e26a74921f..c44cff7e50 100644
--- a/tests/qemucapabilitiesdata/caps_5.1.0.x86_64.replies
+++ b/tests/qemucapabilitiesdata/caps_5.1.0.x86_64.replies
@@ -21,7 +21,7 @@
"minor": 0,
"major": 5
},
- "package": "v5.0.0-34-g648db19685"
+ "package": "v5.0.0-870-g5cc7a54c2e"
},
"id": "libvirt-2"
}
@@ -618,10 +618,6 @@
{
"return": [
- {
- "name": "ich9-usb-uhci5",
- "parent": "pci-uhci-usb"
- },
{
"name": "pcie-pci-bridge",
"parent": "base-pci-bridge"
@@ -662,6 +658,10 @@
"name": "Denverton-x86_64-cpu",
"parent": "x86_64-cpu"
},
+ {
+ "name": "virtio-rng-device",
+ "parent": "virtio-device"
+ },
{
"name": "filter-buffer",
"parent": "netfilter"
@@ -671,8 +671,8 @@
"parent": "usb-device"
},
{
- "name": "pci-bridge",
- "parent": "base-pci-bridge"
+ "name": "ich9-usb-uhci5",
+ "parent": "pci-uhci-usb"
},
{
"name": "pci-ipmi-bt",
@@ -691,8 +691,8 @@
"parent": "pci-vga"
},
{
- "name": "virtio-rng-device",
- "parent": "virtio-device"
+ "name": "pcm3680_pci",
+ "parent": "pci-device"
},
{
"name": "Haswell-v1-x86_64-cpu",
@@ -703,8 +703,8 @@
"parent": "pci-device"
},
{
- "name": "core2duo-x86_64-cpu",
- "parent": "x86_64-cpu"
+ "name": "pci-bridge",
+ "parent": "base-pci-bridge"
},
{
"name": "kvm-pit",
@@ -723,8 +723,8 @@
"parent": "virtio-device"
},
{
- "name": "pcm3680_pci",
- "parent": "pci-device"
+ "name": "core2duo-x86_64-cpu",
+ "parent": "x86_64-cpu"
},
{
"name": "virtio-blk-pci-transitional",
@@ -1086,14 +1086,14 @@
"name": "pxb-pcie",
"parent": "pci-device"
},
- {
- "name": "Haswell-IBRS-x86_64-cpu",
- "parent": "x86_64-cpu"
- },
{
"name": "virtio-scsi-device",
"parent": "virtio-scsi-common"
},
+ {
+ "name": "Haswell-IBRS-x86_64-cpu",
+ "parent": "x86_64-cpu"
+ },
{
"name": "input-barrier",
"parent": "object"
@@ -1690,6 +1690,10 @@
"name": "Dhyana-v1-x86_64-cpu",
"parent": "x86_64-cpu"
},
+ {
+ "name": "pc-i440fx-5.1-machine",
+ "parent": "generic-pc-machine"
+ },
{
"name": "sysbus-fdc",
"parent": "base-sysbus-fdc"
@@ -1859,8 +1863,8 @@
"parent": "megasas-base"
},
{
- "name": "vmcoreinfo",
- "parent": "device"
+ "name": "chardev-braille",
+ "parent": "chardev"
},
{
"name": "virtio-iommu-pci",
@@ -1871,12 +1875,12 @@
"parent": "x86_64-cpu"
},
{
- "name": "tpci200",
- "parent": "pci-device"
+ "name": "vmcoreinfo",
+ "parent": "device"
},
{
- "name": "chardev-braille",
- "parent": "chardev"
+ "name": "tpci200",
+ "parent": "pci-device"
},
{
"name": "rocker",
@@ -1914,6 +1918,10 @@
"name": "qemu-console",
"parent": "object"
},
+ {
+ "name": "chardev-socket",
+ "parent": "chardev"
+ },
{
"name": "input-linux",
"parent": "object"
@@ -1962,14 +1970,14 @@
"name": "cs4231a",
"parent": "isa-device"
},
- {
- "name": "chardev-socket",
- "parent": "chardev"
- },
{
"name": "scsi-hd",
"parent": "scsi-disk-base"
},
+ {
+ "name": "clock",
+ "parent": "object"
+ },
{
"name": "usb-kbd",
"parent": "usb-hid"
@@ -1998,6 +2006,10 @@
"name": "virtio-net-device",
"parent": "virtio-device"
},
+ {
+ "name": "ccid-card-emulated",
+ "parent": "ccid-card"
+ },
{
"name": "pc-q35-2.9-machine",
"parent": "generic-pc-machine"
@@ -2027,15 +2039,15 @@
"parent": "virtio-iommu-device-base"
},
{
- "name": "ccid-card-emulated",
- "parent": "ccid-card"
+ "name": "pc-i440fx-1.7-machine",
+ "parent": "generic-pc-machine"
},
{
"name": "Westmere-v2-x86_64-cpu",
"parent": "x86_64-cpu"
},
{
- "name": "pc-i440fx-1.7-machine",
+ "name": "pc-q35-5.1-machine",
"parent": "generic-pc-machine"
},
{
@@ -2138,14 +2150,14 @@
"name": "pc-dimm",
"parent": "device"
},
- {
- "name": "virtio-balloon-pci-non-transitional",
- "parent": "virtio-balloon-pci-base"
- },
{
"name": "virtio-net-pci-transitional",
"parent": "virtio-net-pci-base"
},
+ {
+ "name": "virtio-balloon-pci-non-transitional",
+ "parent": "virtio-balloon-pci-base"
+ },
{
"name": "ipmi-bmc-sim",
"parent": "ipmi-bmc"
@@ -8013,6 +8025,15 @@
"cpu-max": 288,
"deprecated": false
},
+ {
+ "hotpluggable-cpus": true,
+ "name": "pc-q35-5.1",
+ "numa-mem-supported": true,
+ "default-cpu-type": "qemu64-x86_64-cpu",
+ "cpu-max": 288,
+ "deprecated": false,
+ "alias": "q35"
+ },
{
"hotpluggable-cpus": true,
"name": "pc-i440fx-1.7",
@@ -8077,6 +8098,16 @@
"cpu-max": 255,
"deprecated": false
},
+ {
+ "hotpluggable-cpus": true,
+ "name": "pc-i440fx-5.1",
+ "numa-mem-supported": true,
+ "default-cpu-type": "qemu64-x86_64-cpu",
+ "is-default": true,
+ "cpu-max": 255,
+ "deprecated": false,
+ "alias": "pc"
+ },
{
"hotpluggable-cpus": true,
"name": "pc-i440fx-2.9",
@@ -8171,8 +8202,7 @@
"numa-mem-supported": true,
"default-cpu-type": "qemu64-x86_64-cpu",
"cpu-max": 288,
- "deprecated": false,
- "alias": "q35"
+ "deprecated": false
},
{
"hotpluggable-cpus": true,
@@ -8243,10 +8273,8 @@
"name": "pc-i440fx-5.0",
"numa-mem-supported": true,
"default-cpu-type": "qemu64-x86_64-cpu",
- "is-default": true,
"cpu-max": 255,
- "deprecated": false,
- "alias": "pc"
+ "deprecated": false
},
{
"hotpluggable-cpus": true,
@@ -10852,6 +10880,15 @@
},
{
"parameters": [
+ {
+ "name": "abstract",
+ "type": "boolean"
+ },
+ {
+ "name": "tight",
+ "default": "on",
+ "type": "boolean"
+ },
{
"name": "logappend",
"type": "boolean"
@@ -16185,6 +16222,11 @@
"default": null,
"type": "int"
},
+ {
+ "name": "cpu-throttle-tailslow",
+ "default": null,
+ "type": "bool"
+ },
{
"name": "tls-creds",
"default": null,
@@ -16316,6 +16358,11 @@
"default": null,
"type": "int"
},
+ {
+ "name": "cpu-throttle-tailslow",
+ "default": null,
+ "type": "bool"
+ },
{
"name": "tls-creds",
"default": null,
@@ -21208,6 +21255,10 @@
"name": "cache-miss-rate",
"type": "number"
},
+ {
+ "name": "encoding-rate",
+ "type": "number"
+ },
{
"name": "overflow",
"type": "int"
@@ -22789,6 +22840,11 @@
"name": "refcount-bits",
"default": null,
"type": "int"
+ },
+ {
+ "name": "compression-type",
+ "default": null,
+ "type": "499"
}
],
"meta-type": "object"
@@ -22870,7 +22926,7 @@
{
"name": "redundancy",
"default": null,
- "type": "499"
+ "type": "500"
},
{
"name": "object-size",
@@ -22937,7 +22993,7 @@
{
"name": "subformat",
"default": null,
- "type": "500"
+ "type": "501"
},
{
"name": "block-state-zero",
@@ -22966,7 +23022,7 @@
{
"name": "subformat",
"default": null,
- "type": "501"
+ "type": "502"
},
{
"name": "backing-file",
@@ -22976,7 +23032,7 @@
{
"name": "adapter-type",
"default": null,
- "type": "502"
+ "type": "503"
},
{
"name": "hwversion",
@@ -23005,7 +23061,7 @@
{
"name": "subformat",
"default": null,
- "type": "503"
+ "type": "504"
},
{
"name": "force-size",
@@ -23101,7 +23157,7 @@
"members": [
{
"name": "data",
- "type": "504"
+ "type": "505"
}
],
"meta-type": "object"
@@ -23111,7 +23167,7 @@
"members": [
{
"name": "data",
- "type": "505"
+ "type": "506"
}
],
"meta-type": "object"
@@ -23121,7 +23177,7 @@
"members": [
{
"name": "data",
- "type": "506"
+ "type": "507"
}
],
"meta-type": "object"
@@ -23131,7 +23187,7 @@
"members": [
{
"name": "data",
- "type": "507"
+ "type": "508"
}
],
"meta-type": "object"
@@ -23141,7 +23197,7 @@
"members": [
{
"name": "data",
- "type": "508"
+ "type": "509"
}
],
"meta-type": "object"
@@ -23151,7 +23207,7 @@
"members": [
{
"name": "data",
- "type": "509"
+ "type": "510"
}
],
"meta-type": "object"
@@ -23161,7 +23217,7 @@
"members": [
{
"name": "data",
- "type": "510"
+ "type": "511"
}
],
"meta-type": "object"
@@ -23171,7 +23227,7 @@
"members": [
{
"name": "data",
- "type": "511"
+ "type": "512"
}
],
"meta-type": "object"
@@ -23181,7 +23237,7 @@
"members": [
{
"name": "data",
- "type": "512"
+ "type": "513"
}
],
"meta-type": "object"
@@ -23191,7 +23247,7 @@
"members": [
{
"name": "data",
- "type": "513"
+ "type": "514"
}
],
"meta-type": "object"
@@ -23201,7 +23257,7 @@
"members": [
{
"name": "data",
- "type": "514"
+ "type": "515"
}
],
"meta-type": "object"
@@ -23234,7 +23290,7 @@
"members": [
{
"name": "data",
- "type": "515"
+ "type": "516"
}
],
"meta-type": "object"
@@ -23244,7 +23300,7 @@
"members": [
{
"name": "data",
- "type": "516"
+ "type": "517"
}
],
"meta-type": "object"
@@ -23272,7 +23328,7 @@
"members": [
{
"name": "data",
- "type": "517"
+ "type": "518"
}
],
"meta-type": "object"
@@ -23292,7 +23348,7 @@
"members": [
{
"name": "data",
- "type": "518"
+ "type": "519"
}
],
"meta-type": "object"
@@ -23302,7 +23358,7 @@
"members": [
{
"name": "data",
- "type": "519"
+ "type": "520"
}
],
"meta-type": "object"
@@ -23312,7 +23368,7 @@
"members": [
{
"name": "data",
- "type": "520"
+ "type": "521"
}
],
"meta-type": "object"
@@ -23333,6 +23389,16 @@
{
"name": "path",
"type": "str"
+ },
+ {
+ "name": "tight",
+ "default": null,
+ "type": "bool"
+ },
+ {
+ "name": "abstract",
+ "default": null,
+ "type": "bool"
}
],
"meta-type": "object"
@@ -23374,7 +23440,7 @@
"members": [
{
"name": "data",
- "type": "521"
+ "type": "522"
}
],
"meta-type": "object"
@@ -23639,7 +23705,7 @@
"members": [
{
"name": "bus",
- "type": "522"
+ "type": "523"
},
{
"name": "devices",
@@ -23783,7 +23849,7 @@
"members": [
{
"name": "data",
- "type": "523"
+ "type": "524"
}
],
"meta-type": "object"
@@ -23793,7 +23859,7 @@
"members": [
{
"name": "data",
- "type": "524"
+ "type": "525"
}
],
"meta-type": "object"
@@ -23803,7 +23869,7 @@
"members": [
{
"name": "data",
- "type": "525"
+ "type": "526"
}
],
"meta-type": "object"
@@ -23998,7 +24064,7 @@
"members": [
{
"name": "type",
- "type": "526"
+ "type": "527"
},
{
"name": "hash",
@@ -24077,13 +24143,13 @@
},
{
"case": "luks",
- "type": "528"
+ "type": "529"
}
],
"members": [
{
"name": "format",
- "type": "527"
+ "type": "528"
}
],
"meta-type": "object"
@@ -24098,27 +24164,34 @@
},
{
"name": "499",
+ "meta-type": "enum",
+ "values": [
+ "zlib"
+ ]
+ },
+ {
+ "name": "500",
"tag": "type",
"variants": [
{
"case": "full",
- "type": "530"
+ "type": "531"
},
{
"case": "erasure-coded",
- "type": "531"
+ "type": "532"
}
],
"members": [
{
"name": "type",
- "type": "529"
+ "type": "530"
}
],
"meta-type": "object"
},
{
- "name": "500",
+ "name": "501",
"meta-type": "enum",
"values": [
"dynamic",
@@ -24126,7 +24199,7 @@
]
},
{
- "name": "501",
+ "name": "502",
"meta-type": "enum",
"values": [
"monolithicSparse",
@@ -24137,7 +24210,7 @@
]
},
{
- "name": "502",
+ "name": "503",
"meta-type": "enum",
"values": [
"ide",
@@ -24147,7 +24220,7 @@
]
},
{
- "name": "503",
+ "name": "504",
"meta-type": "enum",
"values": [
"dynamic",
@@ -24155,7 +24228,7 @@
]
},
{
- "name": "504",
+ "name": "505",
"members": [
{
"name": "logfile",
@@ -24185,7 +24258,7 @@
"meta-type": "object"
},
{
- "name": "505",
+ "name": "506",
"members": [
{
"name": "logfile",
@@ -24205,7 +24278,7 @@
"meta-type": "object"
},
{
- "name": "506",
+ "name": "507",
"members": [
{
"name": "logfile",
@@ -24270,7 +24343,7 @@
"meta-type": "object"
},
{
- "name": "507",
+ "name": "508",
"members": [
{
"name": "logfile",
@@ -24295,7 +24368,7 @@
"meta-type": "object"
},
{
- "name": "508",
+ "name": "509",
"members": [
{
"name": "logfile",
@@ -24311,7 +24384,7 @@
"meta-type": "object"
},
{
- "name": "509",
+ "name": "510",
"members": [
{
"name": "logfile",
@@ -24331,7 +24404,7 @@
"meta-type": "object"
},
{
- "name": "510",
+ "name": "511",
"members": [
{
"name": "logfile",
@@ -24352,7 +24425,7 @@
"meta-type": "object"
},
{
- "name": "511",
+ "name": "512",
"members": [
{
"name": "logfile",
@@ -24372,7 +24445,7 @@
"meta-type": "object"
},
{
- "name": "512",
+ "name": "513",
"members": [
{
"name": "logfile",
@@ -24392,7 +24465,7 @@
"meta-type": "object"
},
{
- "name": "513",
+ "name": "514",
"members": [
{
"name": "logfile",
@@ -24428,7 +24501,7 @@
"meta-type": "object"
},
{
- "name": "514",
+ "name": "515",
"members": [
{
"name": "logfile",
@@ -24449,7 +24522,7 @@
"meta-type": "object"
},
{
- "name": "515",
+ "name": "516",
"members": [
{
"name": "path",
@@ -24465,7 +24538,7 @@
"meta-type": "object"
},
{
- "name": "516",
+ "name": "517",
"members": [
{
"name": "chardev",
@@ -24475,7 +24548,7 @@
"meta-type": "object"
},
{
- "name": "517",
+ "name": "518",
"meta-type": "enum",
"values": [
"unmapped",
@@ -24629,7 +24702,7 @@
]
},
{
- "name": "518",
+ "name": "519",
"members": [
{
"name": "key",
@@ -24643,11 +24716,11 @@
"meta-type": "object"
},
{
- "name": "519",
+ "name": "520",
"members": [
{
"name": "button",
- "type": "532"
+ "type": "533"
},
{
"name": "down",
@@ -24657,11 +24730,11 @@
"meta-type": "object"
},
{
- "name": "520",
+ "name": "521",
"members": [
{
"name": "axis",
- "type": "533"
+ "type": "534"
},
{
"name": "value",
@@ -24671,13 +24744,13 @@
"meta-type": "object"
},
{
- "name": "521",
+ "name": "522",
"members": [
],
"meta-type": "object"
},
{
- "name": "522",
+ "name": "523",
"members": [
{
"name": "number",
@@ -24693,21 +24766,21 @@
},
{
"name": "io_range",
- "type": "534"
+ "type": "535"
},
{
"name": "memory_range",
- "type": "534"
+ "type": "535"
},
{
"name": "prefetchable_range",
- "type": "534"
+ "type": "535"
}
],
"meta-type": "object"
},
{
- "name": "523",
+ "name": "524",
"members": [
{
"name": "compat",
@@ -24740,18 +24813,22 @@
{
"name": "encrypt",
"default": null,
- "type": "535"
+ "type": "536"
},
{
"name": "bitmaps",
"default": null,
- "type": "[536]"
+ "type": "[537]"
+ },
+ {
+ "name": "compression-type",
+ "type": "499"
}
],
"meta-type": "object"
},
{
- "name": "524",
+ "name": "525",
"members": [
{
"name": "create-type",
@@ -24773,7 +24850,7 @@
"meta-type": "object"
},
{
- "name": "525",
+ "name": "526",
"members": [
{
"name": "cipher-alg",
@@ -24810,13 +24887,13 @@
},
{
"name": "slots",
- "type": "[537]"
+ "type": "[538]"
}
],
"meta-type": "object"
},
{
- "name": "526",
+ "name": "527",
"meta-type": "enum",
"values": [
"md5",
@@ -24824,7 +24901,7 @@
]
},
{
- "name": "527",
+ "name": "528",
"meta-type": "enum",
"values": [
"qcow",
@@ -24832,7 +24909,7 @@
]
},
{
- "name": "528",
+ "name": "529",
"members": [
{
"name": "key-secret",
@@ -24873,7 +24950,7 @@
"meta-type": "object"
},
{
- "name": "529",
+ "name": "530",
"meta-type": "enum",
"values": [
"full",
@@ -24881,7 +24958,7 @@
]
},
{
- "name": "530",
+ "name": "531",
"members": [
{
"name": "copies",
@@ -24891,7 +24968,7 @@
"meta-type": "object"
},
{
- "name": "531",
+ "name": "532",
"members": [
{
"name": "data-strips",
@@ -24905,7 +24982,7 @@
"meta-type": "object"
},
{
- "name": "532",
+ "name": "533",
"meta-type": "enum",
"values": [
"left",
@@ -24918,7 +24995,7 @@
]
},
{
- "name": "533",
+ "name": "534",
"meta-type": "enum",
"values": [
"x",
@@ -24926,7 +25003,7 @@
]
},
{
- "name": "534",
+ "name": "535",
"members": [
{
"name": "base",
@@ -24940,12 +25017,12 @@
"meta-type": "object"
},
{
- "name": "535",
+ "name": "536",
"tag": "format",
"variants": [
{
"case": "luks",
- "type": "525"
+ "type": "526"
},
{
"case": "aes",
@@ -24961,12 +25038,12 @@
"meta-type": "object"
},
{
- "name": "[536]",
- "element-type": "536",
+ "name": "[537]",
+ "element-type": "537",
"meta-type": "array"
},
{
- "name": "536",
+ "name": "537",
"members": [
{
"name": "name",
@@ -24978,7 +25055,7 @@
},
{
"name": "flags",
- "type": "[538]"
+ "type": "[539]"
}
],
"meta-type": "object"
@@ -24989,12 +25066,12 @@
"meta-type": "array"
},
{
- "name": "[537]",
- "element-type": "537",
+ "name": "[538]",
+ "element-type": "538",
"meta-type": "array"
},
{
- "name": "537",
+ "name": "538",
"members": [
{
"name": "active",
@@ -25018,12 +25095,12 @@
"meta-type": "object"
},
{
- "name": "[538]",
- "element-type": "538",
+ "name": "[539]",
+ "element-type": "539",
"meta-type": "array"
},
{
- "name": "538",
+ "name": "539",
"meta-type": "enum",
"values": [
"in-use",
@@ -28558,6 +28635,15 @@
"cpu-max": 288,
"deprecated": false
},
+ {
+ "hotpluggable-cpus": true,
+ "name": "pc-q35-5.1",
+ "numa-mem-supported": true,
+ "default-cpu-type": "qemu64-x86_64-cpu",
+ "cpu-max": 288,
+ "deprecated": false,
+ "alias": "q35"
+ },
{
"hotpluggable-cpus": true,
"name": "pc-i440fx-1.7",
@@ -28622,6 +28708,16 @@
"cpu-max": 255,
"deprecated": false
},
+ {
+ "hotpluggable-cpus": true,
+ "name": "pc-i440fx-5.1",
+ "numa-mem-supported": true,
+ "default-cpu-type": "qemu64-x86_64-cpu",
+ "is-default": true,
+ "cpu-max": 255,
+ "deprecated": false,
+ "alias": "pc"
+ },
{
"hotpluggable-cpus": true,
"name": "pc-i440fx-2.9",
@@ -28716,8 +28812,7 @@
"numa-mem-supported": true,
"default-cpu-type": "qemu64-x86_64-cpu",
"cpu-max": 288,
- "deprecated": false,
- "alias": "q35"
+ "deprecated": false
},
{
"hotpluggable-cpus": true,
@@ -28788,10 +28883,8 @@
"name": "pc-i440fx-5.0",
"numa-mem-supported": true,
"default-cpu-type": "qemu64-x86_64-cpu",
- "is-default": true,
"cpu-max": 255,
- "deprecated": false,
- "alias": "pc"
+ "deprecated": false
},
{
"hotpluggable-cpus": true,
diff --git a/tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml
b/tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml
index c2bc121f73..3f538628b3 100644
--- a/tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml
@@ -237,7 +237,7 @@
<version>5000050</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>43100242</microcodeVersion>
- <package>v5.0.0-34-g648db19685</package>
+ <package>v5.0.0-870-g5cc7a54c2e</package>
<arch>x86_64</arch>
<hostCPU type='kvm' model='base' migratability='yes'>
<property name='vmx-entry-load-rtit-ctl' type='boolean'
value='false'/>
@@ -1328,7 +1328,7 @@
</cpu>
<cpu type='kvm' name='486-v1' typename='486-v1-x86_64-cpu'
usable='yes'/>
<cpu type='kvm' name='486' typename='486-x86_64-cpu'
usable='yes'/>
- <machine type='kvm' name='pc-i440fx-5.0' alias='pc'
hotplugCpus='yes' maxCpus='255' default='yes'
defaultCPU='qemu64-x86_64-cpu' numaMemSupported='yes'/>
+ <machine type='kvm' name='pc-i440fx-5.1' alias='pc'
hotplugCpus='yes' maxCpus='255' default='yes'
defaultCPU='qemu64-x86_64-cpu' numaMemSupported='yes'/>
<machine type='kvm' name='pc-i440fx-2.12' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-i440fx-2.0' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-q35-4.2' hotplugCpus='yes'
maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
@@ -1341,6 +1341,7 @@
<machine type='kvm' name='pc-i440fx-2.7' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-q35-2.4' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-q35-2.10' hotplugCpus='yes'
maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
+ <machine type='kvm' name='pc-q35-5.1' alias='q35'
hotplugCpus='yes' maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-i440fx-1.7' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-q35-2.9' hotplugCpus='yes'
maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-i440fx-2.11' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
@@ -1360,7 +1361,7 @@
<machine type='kvm' name='pc-i440fx-2.6' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-q35-4.0.1' hotplugCpus='yes'
maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-i440fx-1.6' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
- <machine type='kvm' name='pc-q35-5.0' alias='q35'
hotplugCpus='yes' maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
+ <machine type='kvm' name='pc-q35-5.0' hotplugCpus='yes'
maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-q35-2.8' hotplugCpus='yes'
maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-i440fx-2.10' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-q35-3.0' hotplugCpus='yes'
maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
@@ -1369,6 +1370,7 @@
<machine type='kvm' name='pc-i440fx-2.3' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-1.2' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-i440fx-4.0' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
+ <machine type='kvm' name='pc-i440fx-5.0' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-i440fx-2.8' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-q35-2.5' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='kvm' name='pc-i440fx-3.0' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
@@ -2970,7 +2972,7 @@
</cpu>
<cpu type='tcg' name='486-v1' typename='486-v1-x86_64-cpu'
usable='yes'/>
<cpu type='tcg' name='486' typename='486-x86_64-cpu'
usable='yes'/>
- <machine type='tcg' name='pc-i440fx-5.0' alias='pc'
hotplugCpus='yes' maxCpus='255' default='yes'
defaultCPU='qemu64-x86_64-cpu' numaMemSupported='yes'/>
+ <machine type='tcg' name='pc-i440fx-5.1' alias='pc'
hotplugCpus='yes' maxCpus='255' default='yes'
defaultCPU='qemu64-x86_64-cpu' numaMemSupported='yes'/>
<machine type='tcg' name='pc-i440fx-2.12' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-i440fx-2.0' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-q35-4.2' hotplugCpus='yes'
maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
@@ -2983,6 +2985,7 @@
<machine type='tcg' name='pc-i440fx-2.7' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-q35-2.4' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-q35-2.10' hotplugCpus='yes'
maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
+ <machine type='tcg' name='pc-q35-5.1' alias='q35'
hotplugCpus='yes' maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-i440fx-1.7' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-q35-2.9' hotplugCpus='yes'
maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-i440fx-2.11' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
@@ -3002,7 +3005,7 @@
<machine type='tcg' name='pc-i440fx-2.6' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-q35-4.0.1' hotplugCpus='yes'
maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-i440fx-1.6' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
- <machine type='tcg' name='pc-q35-5.0' alias='q35'
hotplugCpus='yes' maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
+ <machine type='tcg' name='pc-q35-5.0' hotplugCpus='yes'
maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-q35-2.8' hotplugCpus='yes'
maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-i440fx-2.10' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-q35-3.0' hotplugCpus='yes'
maxCpus='288' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
@@ -3011,6 +3014,7 @@
<machine type='tcg' name='pc-i440fx-2.3' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-1.2' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-i440fx-4.0' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
+ <machine type='tcg' name='pc-i440fx-5.0' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-i440fx-2.8' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-q35-2.5' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
<machine type='tcg' name='pc-i440fx-3.0' hotplugCpus='yes'
maxCpus='255' defaultCPU='qemu64-x86_64-cpu'
numaMemSupported='yes'/>
--
2.26.2
3:27 a.m.
On 6/3/20 9:31 AM, Peter Krempa wrote:
QEMU added the machine types for the 5.1 release so let's update
them.
Other notable changes are 'cpu-throttle-tailslow' migration property,
'zlib' compression for qcow2 images and absrtact socket support.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
As usual, I'll be refreshing this until the release so that we always
have fresh capabilities to prevent any surprises with deprecation and
big updates.
.../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 2 +-
.../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 2 +-
tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 2 +-
.../caps_5.1.0.x86_64.replies | 357 +++++++++++-------
.../caps_5.1.0.x86_64.xml | 14 +-
5 files changed, 237 insertions(+), 140 deletions(-)
Reviewed-by: Michal Privoznik <mprivozn(a)redhat.com>
Maybe we can have another rule that would allow you to push these
without review? I can argue both ways, so I'm just putting it out there.
Michal
3:40 a.m.
On Wed, Jun 03, 2020 at 10:27:57 +0200, Michal Privoznik wrote:
On 6/3/20 9:31 AM, Peter Krempa wrote:
> QEMU added the machine types for the 5.1 release so let's update them.
>
> Other notable changes are 'cpu-throttle-tailslow' migration property,
> 'zlib' compression for qcow2 images and absrtact socket support.
>
> Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
> ---
> As usual, I'll be refreshing this until the release so that we always
> have fresh capabilities to prevent any surprises with deprecation and
> big updates.
>
> .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 2 +-
> .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 2 +-
> tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 2 +-
> .../caps_5.1.0.x86_64.replies | 357 +++++++++++-------
> .../caps_5.1.0.x86_64.xml | 14 +-
> 5 files changed, 237 insertions(+), 140 deletions(-)
Reviewed-by: Michal Privoznik <mprivozn(a)redhat.com>
Maybe we can have another rule that would allow you to push these without
review? I can argue both ways, so I'm just putting it out there.
Yeah. I thought about that too.
Specifically one thing I'd like to avoid is carelessness in case of the
update. Specifically if there is some form of removal (flag being
removed and such) we need to be careful and consider the implications.
In this very specific case there's nothing of note and I'd be okay with
just pushing it, but the rules if we wanted to codify it somehow would
require to be more nuanced and I don't think I can express all the
caveats.
That's why I didn't really argue for adding a special rule for this.
Also one reason I'm doing periodic upgrades of this is so that others
don't have to do it. The problem here is that the output is very much
dependent on the machine where you run it and I don't want others to
have to update the files when adding a new capability as the difference
becomes unreviewable and may even regress depending on how qemu is
built.
4:11 a.m.
On 6/3/20 10:40 AM, Peter Krempa wrote:
On Wed, Jun 03, 2020 at 10:27:57 +0200, Michal Privoznik wrote:
> On 6/3/20 9:31 AM, Peter Krempa wrote:
>> QEMU added the machine types for the 5.1 release so let's update them.
>>
>> Other notable changes are 'cpu-throttle-tailslow' migration property,
>> 'zlib' compression for qcow2 images and absrtact socket support.
>>
>> Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
>> ---
>> As usual, I'll be refreshing this until the release so that we always
>> have fresh capabilities to prevent any surprises with deprecation and
>> big updates.
>>
>> .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 2 +-
>> .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 2 +-
>> tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 2 +-
>> .../caps_5.1.0.x86_64.replies | 357 +++++++++++-------
>> .../caps_5.1.0.x86_64.xml | 14 +-
>> 5 files changed, 237 insertions(+), 140 deletions(-)
>
> Reviewed-by: Michal Privoznik <mprivozn(a)redhat.com>
>
> Maybe we can have another rule that would allow you to push these without
> review? I can argue both ways, so I'm just putting it out there.
Yeah. I thought about that too.
Specifically one thing I'd like to avoid is carelessness in case of the
update. Specifically if there is some form of removal (flag being
removed and such) we need to be careful and consider the implications.
Well, for that we would need to compare with older capabilities XML and
I don't think we are doing that. Removal between the same capabilities
XML of an unreleased QEMU are uncommon. But I hear what you're saying
and that's my concern too.
In this very specific case there's nothing of note and I'd be okay with
just pushing it, but the rules if we wanted to codify it somehow would
require to be more nuanced and I don't think I can express all the
caveats.
That's why I didn't really argue for adding a special rule for this.
Also one reason I'm doing periodic upgrades of this is so that others
don't have to do it. The problem here is that the output is very much
dependent on the machine where you run it and I don't want others to
have to update the files when adding a new capability as the difference
becomes unreviewable and may even regress depending on how qemu is
built.
This is a long known issue and perhaps it would be worth documenting
somewhere? I think these are QEMU binaries taken from Fedora, is that
so? Maybe we can document configure arguments for QEMU so that it is
reproducible.
Michal
4:29 a.m.
On Wed, Jun 03, 2020 at 11:11:08 +0200, Michal Privoznik wrote:
On 6/3/20 10:40 AM, Peter Krempa wrote:
> On Wed, Jun 03, 2020 at 10:27:57 +0200, Michal Privoznik wrote:
> > On 6/3/20 9:31 AM, Peter Krempa wrote:
> > > QEMU added the machine types for the 5.1 release so let's update
them.
> > >
> > > Other notable changes are 'cpu-throttle-tailslow' migration
property,
> > > 'zlib' compression for qcow2 images and absrtact socket support.
> > >
> > > Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
> > > ---
> > > As usual, I'll be refreshing this until the release so that we always
> > > have fresh capabilities to prevent any surprises with deprecation and
> > > big updates.
> > >
> > > .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 2 +-
> > > .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 2 +-
> > > tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 2 +-
> > > .../caps_5.1.0.x86_64.replies | 357 +++++++++++-------
> > > .../caps_5.1.0.x86_64.xml | 14 +-
> > > 5 files changed, 237 insertions(+), 140 deletions(-)
> >
> > Reviewed-by: Michal Privoznik <mprivozn(a)redhat.com>
> >
> > Maybe we can have another rule that would allow you to push these without
> > review? I can argue both ways, so I'm just putting it out there.
>
> Yeah. I thought about that too.
>
> Specifically one thing I'd like to avoid is carelessness in case of the
> update. Specifically if there is some form of removal (flag being
> removed and such) we need to be careful and consider the implications.
Well, for that we would need to compare with older capabilities XML and I
don't think we are doing that. Removal between the same capabilities XML of
I certainly am doing that when generating files after the release to
ensure that we don't regress in anything. Obviously only on the level of
detected capabilities.
an unreleased QEMU are uncommon. But I hear what you're saying
and that's my
concern too.
>
> In this very specific case there's nothing of note and I'd be okay with
> just pushing it, but the rules if we wanted to codify it somehow would
> require to be more nuanced and I don't think I can express all the
> caveats.
>
> That's why I didn't really argue for adding a special rule for this.
>
> Also one reason I'm doing periodic upgrades of this is so that others
> don't have to do it. The problem here is that the output is very much
> dependent on the machine where you run it and I don't want others to
> have to update the files when adding a new capability as the difference
> becomes unreviewable and may even regress depending on how qemu is
> built.
>
This is a long known issue and perhaps it would be worth documenting
somewhere? I think these are QEMU binaries taken from Fedora, is that so?
Well. They are built on fedora, but certainly not taken from fedora.
It's built from git.
Maybe we can document configure arguments for QEMU so that it is
reproducible.
While I agree that we should do that to take one of the moving parts out
of the equation we still can't do anything about the machine dependance
of the output. Specifically it contains all cpu flags so it really can't
be re-generated reproducibly on a box with even a slightly different
cpu.
Ideally we'd build it with the fedora spec-file, but I got lazy and I'm
usually just re-running configure from my history in this case.
My only idea how to provide stable output is to create a job on a box
which will periodically re-build qemu and fetch the capabilities and
publish them somewhere so that others could grab those and refresh the
caps themselves, but I can't really think of a way how to enable others
do it on their machine whithout messing up the CPU.
4:37 a.m.
On Wed, Jun 03, 2020 at 11:29:36AM +0200, Peter Krempa wrote:
On Wed, Jun 03, 2020 at 11:11:08 +0200, Michal Privoznik wrote:
> On 6/3/20 10:40 AM, Peter Krempa wrote:
> > On Wed, Jun 03, 2020 at 10:27:57 +0200, Michal Privoznik wrote:
> > > On 6/3/20 9:31 AM, Peter Krempa wrote:
> > > > QEMU added the machine types for the 5.1 release so let's update
them.
> > > >
> > > > Other notable changes are 'cpu-throttle-tailslow' migration
property,
> > > > 'zlib' compression for qcow2 images and absrtact socket
support.
> > > >
> > > > Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
> > > > ---
> > > > As usual, I'll be refreshing this until the release so that we
always
> > > > have fresh capabilities to prevent any surprises with deprecation
and
> > > > big updates.
> > > >
> > > > .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 2 +-
> > > > .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 2 +-
> > > > tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 2 +-
> > > > .../caps_5.1.0.x86_64.replies | 357
+++++++++++-------
> > > > .../caps_5.1.0.x86_64.xml | 14 +-
> > > > 5 files changed, 237 insertions(+), 140 deletions(-)
> > >
> > > Reviewed-by: Michal Privoznik <mprivozn(a)redhat.com>
> > >
> > > Maybe we can have another rule that would allow you to push these without
> > > review? I can argue both ways, so I'm just putting it out there.
> >
> > Yeah. I thought about that too.
> >
> > Specifically one thing I'd like to avoid is carelessness in case of the
> > update. Specifically if there is some form of removal (flag being
> > removed and such) we need to be careful and consider the implications.
>
> Well, for that we would need to compare with older capabilities XML and I
> don't think we are doing that. Removal between the same capabilities XML of
I certainly am doing that when generating files after the release to
ensure that we don't regress in anything. Obviously only on the level of
detected capabilities.
> an unreleased QEMU are uncommon. But I hear what you're saying and that's
my
> concern too.
>
> >
> > In this very specific case there's nothing of note and I'd be okay
with
> > just pushing it, but the rules if we wanted to codify it somehow would
> > require to be more nuanced and I don't think I can express all the
> > caveats.
> >
> > That's why I didn't really argue for adding a special rule for this.
> >
> > Also one reason I'm doing periodic upgrades of this is so that others
> > don't have to do it. The problem here is that the output is very much
> > dependent on the machine where you run it and I don't want others to
> > have to update the files when adding a new capability as the difference
> > becomes unreviewable and may even regress depending on how qemu is
> > built.
> >
>
> This is a long known issue and perhaps it would be worth documenting
> somewhere? I think these are QEMU binaries taken from Fedora, is that so?
Well. They are built on fedora, but certainly not taken from fedora.
It's built from git.
> Maybe we can document configure arguments for QEMU so that it is
> reproducible.
While I agree that we should do that to take one of the moving parts out
of the equation we still can't do anything about the machine dependance
of the output. Specifically it contains all cpu flags so it really can't
be re-generated reproducibly on a box with even a slightly different
cpu.
Ideally we'd build it with the fedora spec-file, but I got lazy and I'm
usually just re-running configure from my history in this case.
My only idea how to provide stable output is to create a job on a box
which will periodically re-build qemu and fetch the capabilities and
publish them somewhere so that others could grab those and refresh the
caps themselves, but I can't really think of a way how to enable others
do it on their machine whithout messing up the CPU.
You beat me in the response time wrt reply :). Hmm, how about we add this as a
job to lcitool which controls how virt-install is spawned, that way + an Ansible
playbook you always get a reproducible environment?
Erik
4:45 a.m.
On Wed, Jun 03, 2020 at 11:37:21 +0200, Erik Skultety wrote:
On Wed, Jun 03, 2020 at 11:29:36AM +0200, Peter Krempa wrote:
> On Wed, Jun 03, 2020 at 11:11:08 +0200, Michal Privoznik wrote:
> > On 6/3/20 10:40 AM, Peter Krempa wrote:
> > > On Wed, Jun 03, 2020 at 10:27:57 +0200, Michal Privoznik wrote:
> > > > On 6/3/20 9:31 AM, Peter Krempa wrote:
[...]
> Well. They are built on fedora, but certainly not taken from
fedora.
> It's built from git.
>
> > Maybe we can document configure arguments for QEMU so that it is
> > reproducible.
>
> While I agree that we should do that to take one of the moving parts out
> of the equation we still can't do anything about the machine dependance
> of the output. Specifically it contains all cpu flags so it really can't
> be re-generated reproducibly on a box with even a slightly different
> cpu.
>
> Ideally we'd build it with the fedora spec-file, but I got lazy and I'm
> usually just re-running configure from my history in this case.
>
> My only idea how to provide stable output is to create a job on a box
> which will periodically re-build qemu and fetch the capabilities and
> publish them somewhere so that others could grab those and refresh the
> caps themselves, but I can't really think of a way how to enable others
> do it on their machine whithout messing up the CPU.
You beat me in the response time wrt reply :). Hmm, how about we add this as a
job to lcitool which controls how virt-install is spawned, that way + an Ansible
playbook you always get a reproducible environment?
I don't think that's a particularly worthwhile idea. It would have to
run fully emulated to shield from cpu differences which would make it
super slow. In such case I'll rather periodically or on request update
it myself rather than deal with something which takes ages.
5:39 a.m.
On Wed, Jun 03, 2020 at 11:45:49 +0200, Peter Krempa wrote:
On Wed, Jun 03, 2020 at 11:37:21 +0200, Erik Skultety wrote:
> On Wed, Jun 03, 2020 at 11:29:36AM +0200, Peter Krempa wrote:
> > On Wed, Jun 03, 2020 at 11:11:08 +0200, Michal Privoznik wrote:
> > > On 6/3/20 10:40 AM, Peter Krempa wrote:
> > > > On Wed, Jun 03, 2020 at 10:27:57 +0200, Michal Privoznik wrote:
> > > > > On 6/3/20 9:31 AM, Peter Krempa wrote:
[...]
> > Well. They are built on fedora, but certainly not taken from fedora.
> > It's built from git.
> >
> > > Maybe we can document configure arguments for QEMU so that it is
> > > reproducible.
> >
> > While I agree that we should do that to take one of the moving parts out
> > of the equation we still can't do anything about the machine dependance
> > of the output. Specifically it contains all cpu flags so it really can't
> > be re-generated reproducibly on a box with even a slightly different
> > cpu.
> >
> > Ideally we'd build it with the fedora spec-file, but I got lazy and
I'm
> > usually just re-running configure from my history in this case.
> >
> > My only idea how to provide stable output is to create a job on a box
> > which will periodically re-build qemu and fetch the capabilities and
> > publish them somewhere so that others could grab those and refresh the
> > caps themselves, but I can't really think of a way how to enable others
> > do it on their machine whithout messing up the CPU.
>
> You beat me in the response time wrt reply :). Hmm, how about we add this as a
> job to lcitool which controls how virt-install is spawned, that way + an Ansible
> playbook you always get a reproducible environment?
I don't think that's a particularly worthwhile idea. It would have to
run fully emulated to shield from cpu differences which would make it
super slow. In such case I'll rather periodically or on request update
it myself rather than deal with something which takes ages.
Also the problem of having a stable way to generate capabilities is
orthogonal to the original problem of whether to review the capabilities
or not.
I still think manual review is necessary regardless of how stable the
way to generate the capabilities is and in some cases there are even
differences which break tests (recent dropping of the 0.13 machine type
from upstream qemu, deprecation of some commands etc.) so I don't see
a way how this part can be avoided or any reasonably simple set of rules
for avoiding review to be established.
Obviously having a stable way to create capabilities would be certainly
desirable for other scenarios, but not at the cost of running it in TCG.
If we want to achieve that we probably will need a way to strip cpu
related commands from the capabilities and leave cpu probing for a
different test.
This in the end may be desirable due to other reasons as well, but I'm
certainly not sure how to achieve that. As of such I'll gladly continue
updating the capabilities on request by others for now as it doesn't
really cause any burden for me and I need to update it anyways for stuff
I'm developing.
4:34 a.m.
On Wed, Jun 03, 2020 at 11:11:08AM +0200, Michal Privoznik wrote:
On 6/3/20 10:40 AM, Peter Krempa wrote:
> On Wed, Jun 03, 2020 at 10:27:57 +0200, Michal Privoznik wrote:
> > On 6/3/20 9:31 AM, Peter Krempa wrote:
> > > QEMU added the machine types for the 5.1 release so let's update
them.
> > >
> > > Other notable changes are 'cpu-throttle-tailslow' migration
property,
> > > 'zlib' compression for qcow2 images and absrtact socket support.
> > >
> > > Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
> > > ---
> > > As usual, I'll be refreshing this until the release so that we always
> > > have fresh capabilities to prevent any surprises with deprecation and
> > > big updates.
> > >
> > > .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 2 +-
> > > .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 2 +-
> > > tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 2 +-
> > > .../caps_5.1.0.x86_64.replies | 357 +++++++++++-------
> > > .../caps_5.1.0.x86_64.xml | 14 +-
> > > 5 files changed, 237 insertions(+), 140 deletions(-)
> >
> > Reviewed-by: Michal Privoznik <mprivozn(a)redhat.com>
> >
> > Maybe we can have another rule that would allow you to push these without
> > review? I can argue both ways, so I'm just putting it out there.
>
> Yeah. I thought about that too.
>
> Specifically one thing I'd like to avoid is carelessness in case of the
> update. Specifically if there is some form of removal (flag being
> removed and such) we need to be careful and consider the implications.
Well, for that we would need to compare with older capabilities XML and I
don't think we are doing that. Removal between the same capabilities XML of
an unreleased QEMU are uncommon. But I hear what you're saying and that's my
concern too.
>
> In this very specific case there's nothing of note and I'd be okay with
> just pushing it, but the rules if we wanted to codify it somehow would
> require to be more nuanced and I don't think I can express all the
> caveats.
>
> That's why I didn't really argue for adding a special rule for this.
>
> Also one reason I'm doing periodic upgrades of this is so that others
> don't have to do it. The problem here is that the output is very much
> dependent on the machine where you run it and I don't want others to
> have to update the files when adding a new capability as the difference
> becomes unreviewable and may even regress depending on how qemu is
> built.
>
This is a long known issue and perhaps it would be worth documenting
somewhere? I think these are QEMU binaries taken from Fedora, is that so?
Maybe we can document configure arguments for QEMU so that it is
reproducible.
Not only that, we could set up an upstream fedora VM following those steps
(not just steps but the overall HW setup to unify the whole process) and
generating the capabilities whenever new qemu is tagged in git. Of course,
sometimes you need them earlier than an RC is tagged, but still, I think it
would be beneficial to automate this process by setting up the agent in a way
it would send a patch/MR against libvirt.
If it turns out this to be desirable from upstream libvirt POV, I can set up
such an upstream runner.
Erik
4:49 a.m.
On Wed, Jun 03, 2020 at 11:34:07 +0200, Erik Skultety wrote:
On Wed, Jun 03, 2020 at 11:11:08AM +0200, Michal Privoznik wrote:
> On 6/3/20 10:40 AM, Peter Krempa wrote:
> > On Wed, Jun 03, 2020 at 10:27:57 +0200, Michal Privoznik wrote:
> > > On 6/3/20 9:31 AM, Peter Krempa wrote:
> > > > QEMU added the machine types for the 5.1 release so let's update
them.
> > > >
> > > > Other notable changes are 'cpu-throttle-tailslow' migration
property,
> > > > 'zlib' compression for qcow2 images and absrtact socket
support.
> > > >
> > > > Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
> > > > ---
> > > > As usual, I'll be refreshing this until the release so that we
always
> > > > have fresh capabilities to prevent any surprises with deprecation
and
> > > > big updates.
> > > >
> > > > .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 2 +-
> > > > .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 2 +-
> > > > tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 2 +-
> > > > .../caps_5.1.0.x86_64.replies | 357
+++++++++++-------
> > > > .../caps_5.1.0.x86_64.xml | 14 +-
> > > > 5 files changed, 237 insertions(+), 140 deletions(-)
> > >
> > > Reviewed-by: Michal Privoznik <mprivozn(a)redhat.com>
> > >
> > > Maybe we can have another rule that would allow you to push these without
> > > review? I can argue both ways, so I'm just putting it out there.
> >
> > Yeah. I thought about that too.
> >
> > Specifically one thing I'd like to avoid is carelessness in case of the
> > update. Specifically if there is some form of removal (flag being
> > removed and such) we need to be careful and consider the implications.
>
> Well, for that we would need to compare with older capabilities XML and I
> don't think we are doing that. Removal between the same capabilities XML of
> an unreleased QEMU are uncommon. But I hear what you're saying and that's
my
> concern too.
>
> >
> > In this very specific case there's nothing of note and I'd be okay
with
> > just pushing it, but the rules if we wanted to codify it somehow would
> > require to be more nuanced and I don't think I can express all the
> > caveats.
> >
> > That's why I didn't really argue for adding a special rule for this.
> >
> > Also one reason I'm doing periodic upgrades of this is so that others
> > don't have to do it. The problem here is that the output is very much
> > dependent on the machine where you run it and I don't want others to
> > have to update the files when adding a new capability as the difference
> > becomes unreviewable and may even regress depending on how qemu is
> > built.
> >
>
> This is a long known issue and perhaps it would be worth documenting
> somewhere? I think these are QEMU binaries taken from Fedora, is that so?
> Maybe we can document configure arguments for QEMU so that it is
> reproducible.
Not only that, we could set up an upstream fedora VM following those steps
(not just steps but the overall HW setup to unify the whole process) and
Are there any machines which are guaranteed to be stable? Machines which
are not in a cloud or something which can just be re-scheduled somewhere
else.
generating the capabilities whenever new qemu is tagged in git. Of
course,
We do this for pre-release versions too. IMO as the qemu dev cycle is
very long we want to periodically re-sync to allow developing features
in parallel and also be notified about deprecations which are detectable
via QMP introspection.
sometimes you need them earlier than an RC is tagged, but still, I
think it
would be beneficial to automate this process by setting up the agent in a way
it would send a patch/MR against libvirt.
Well. It's not worth doing too often though. I can't really quantify
when it's good enough to update. Specifically in some cases the bump
needs to happen as some new feature was added and you'd like to use it
so it definitely doesn't have a reasonable optimization function.
If it turns out this to be desirable from upstream libvirt POV, I can
set up
such an upstream runner.
1633
days inactive
1633
days old
9 comments
3 participants
participants (3)
-
Erik Skultety -
Michal Privoznik -
Peter Krempa