- Devel - libvirt List Archives

[libvirt] [PATCH 0/6] Couple of storage driver improvements
by Michal Privoznik 06 Mar '19

06 Mar '19

*** BLURB HERE *** Michal Prívozník (6): storage_backend_iscsi_direct: Simplify vol zeroing virISCSIDirectReportLuns: Drop ClearVols storageVolWipePattern: Don't take shortcut to refreshPool() storage_driver: Introduce storagePoolRefreshImpl() storagePoolRefreshFailCleanup: Clear volumes on failed refresh virsh-pool: Offer only active pool for pool-refresh completer src/storage/storage_backend_gluster.c | 2 - src/storage/storage_backend_iscsi_direct.c | 21 ++---- src/storage/storage_backend_logical.c | 12 +--- src/storage/storage_backend_rbd.c | 4 +- src/storage/storage_driver.c | 77 ++++++++++++---------- src/storage/storage_util.c | 2 - tools/virsh-pool.c | 2 +- 7 files changed, 55 insertions(+), 65 deletions(-) -- 2.19.2

1 7

[libvirt] [PATCH] qemu: Don't set migration caps when changing postcopy bandwidth
by Jiri Denemark 06 Mar '19

06 Mar '19

The qemuMigrationParamsApply internal API was designed to apply all migration parameters and capabilities before we start to migrate a domain. The API can also be called outside migration job, e.g., via a call to qemuDomainMigrateSetMaxSpeed with VIR_DOMAIN_MIGRATE_MAX_SPEED_POSTCOPY flag, but in that case it should only apply migration parameters and ignore capabilities. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- Notes: Best viewed with --ignore-all-space src/qemu/qemu_migration_params.c | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_migration_params.c b/src/qemu/qemu_migration_params.c index 24e5368783..623193cf6c 100644 --- a/src/qemu/qemu_migration_params.c +++ b/src/qemu/qemu_migration_params.c @@ -778,14 +778,23 @@ qemuMigrationParamsApply(virQEMUDriverPtr driver, if (qemuDomainObjEnterMonitorAsync(driver, vm, asyncJob) < 0) return -1; - if (!(caps = qemuMigrationCapsToJSON(priv->migrationCaps, migParams->caps))) - goto cleanup; - - if (virJSONValueArraySize(caps) > 0) { - rc = qemuMonitorSetMigrationCapabilities(priv->mon, caps); - caps = NULL; - if (rc < 0) + if (asyncJob == QEMU_ASYNC_JOB_NONE) { + if (!virBitmapIsAllClear(migParams->caps)) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Migration capabilities can only be set by " + "a migration job")); goto cleanup; + } + } else { + if (!(caps = qemuMigrationCapsToJSON(priv->migrationCaps, migParams->caps))) + goto cleanup; + + if (virJSONValueArraySize(caps) > 0) { + rc = qemuMonitorSetMigrationCapabilities(priv->mon, caps); + caps = NULL; + if (rc < 0) + goto cleanup; + } } /* If QEMU is too old to support xbzrle-cache-size migration parameter, -- 2.21.0

3 5

[libvirt] [PATCH] rpm: add dep on xfsprogs-devel for reflink support
by Daniel P. Berrangé 06 Mar '19

06 Mar '19

Support for XFS reflink clone was added in: commit 8ed874b39b3c330bbcdff434e08995dbb4467285 Author: Julio Faracco <jcfaracco(a)gmail.com> Date: Fri Jul 6 10:43:01 2018 -0300 storage: Rename btrfsCloneFile to support other filesystems. commit 2e11298f938672c5430193277c98b9474a68b1fb Author: Julio Faracco <jcfaracco(a)gmail.com> Date: Fri Jul 6 10:43:00 2018 -0300 configure: Adding XFS library/headers check. But these patches missed that the xfs/xfs.h header is not installed unless you have xfsprogs-devel present. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- libvirt.spec.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libvirt.spec.in b/libvirt.spec.in index 9beffba203..83b43f4ef6 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -326,6 +326,8 @@ BuildRequires: libiscsi-devel BuildRequires: parted-devel # For Multipath support BuildRequires: device-mapper-devel +# For XFS reflink clone support +BuildRequires: xfsprogs-devel %if %{with_storage_rbd} BuildRequires: librados2-devel BuildRequires: librbd1-devel -- 2.20.1

2 1

[libvirt] [PATCH 1/2] security: aa-helper: nvidia rules for gl devices
by Christian Ehrhardt 06 Mar '19

06 Mar '19

Further testing with different devices showed that we need more rules to drive gl backends with nvidia cards. Related denies look like: apparmor="DENIED" operation="open" name="/usr/share/egl/egl_external_platform.d/" requested_mask="r" apparmor="DENIED" operation="open" name="/proc/modules" requested_mask="r" apparmor="DENIED" operation="open" name="/proc/driver/nvidia/params" requested_mask="r" apparmor="DENIED" operation="mknod" name="/dev/nvidiactl" requested_mask="c" Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1817943 Signed-off-by: Christian Ehrhardt <christian.ehrhardt(a)canonical.com> --- src/security/virt-aa-helper.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c index e9120213ff..13b507ff69 100644 --- a/src/security/virt-aa-helper.c +++ b/src/security/virt-aa-helper.c @@ -1279,6 +1279,11 @@ get_files(vahControl * ctl) virBufferAddLit(&buf, " \"/usr/share/drirc.d/{,*.conf}\" r,\n"); virBufferAddLit(&buf, " \"/etc/glvnd/egl_vendor.d/{,*}\" r,\n"); virBufferAddLit(&buf, " \"/usr/share/glvnd/egl_vendor.d/{,*}\" r,\n"); + virBufferAddLit(&buf, " \"/usr/share/egl/egl_external_platform.d/\" r,\n"); + virBufferAddLit(&buf, " \"/usr/share/egl/egl_external_platform.d/*\" r,\n"); + virBufferAddLit(&buf, " \"/proc/modules\" r,\n"); + virBufferAddLit(&buf, " \"/proc/driver/nvidia/params\" r,\n"); + virBufferAddLit(&buf, " \"/dev/nvidiactl\" rw,\n"); virBufferAddLit(&buf, " # Probe DRI device attributes\n"); virBufferAddLit(&buf, " \"/dev/dri/\" r,\n"); virBufferAddLit(&buf, " \"/sys/devices/*/*/{uevent,vendor,device,subsystem_vendor,subsystem_device}\" r,\n"); -- 2.17.1

2 5

[libvirt] [PATCH for-4.0 v4 0/2] virtio: Provide version-specific variants of virtio PCI devices
by Eduardo Habkost 06 Mar '19

06 Mar '19

Existing modern-only device types are not being touched by v3, as they don't need separate variants. However, I plan to implement separate cleanups in the code that calls virtio_pci_force_virtio_1(), first, and then propose additional changes (e.g. deprecating disable-legacy and disable-modern in those device types). Changes v3 -> v4: * Trivial comment fixes (Cornelia Huck) * Test code update (Caio Carrara) Changes v2 -> v3: * Split into two separate patches (type registration helper and introduction of new types) * Rewrote virtio_pci_types_register() completely: * Replaced magic generation of type names with explicit fields in VirtioPCIDeviceTypeInfo * Removed modern_only field (not necessary anymore) * Don't register a separate base type unless necessary Changes v1 -> v2: * Removed *-0.9 devices. Nobody will want to use them, if transitional devices work with legacy drivers (Gerd Hoffmann, Michael S. Tsirkin) * Drop virtio version from name: rename -1.0-transitional to -transitional (Michael S. Tsirkin) * Renamed -1.0 to -non-transitional * Don't add any extra variants to modern-only device types (they don't need it) * Fix typo on TYPE_VIRTIO_INPUT_HOST_PCI (crash reported by Cornelia Huck) * No need to change cast macros for modern-only devices * Rename virtio_register_types() to virtio_pci_types_register() Original patch description: Many of the current virtio-*-pci device types actually represent 3 different types of devices: * virtio 1.0 non-transitional devices * virtio 1.0 transitional devices * virtio 0.9 ("legacy device" in virtio 1.0 terminology) That would be just an annoyance if it didn't break our device/bus compatibility QMP interfaces. With this multi-purpose device type, there's no way to tell management software that transitional devices and legacy devices require a Conventional PCI bus. The multi-purpose device types would also prevent us from telling management software what's the PCI vendor/device ID for them, because their PCI IDs change at runtime depending on the bus where they were plugged. This patch adds separate device types for each of those virtio device flavors: * virtio-*-pci: the existing multi-purpose device types * virtio-*-pci-transitional: virtio-1.0 device supporting legacy drivers * virtio-*-pci-non-transitional: modern-only Reference to previous discussion that originated this idea: https://www.mail-archive.com/qemu-devel@nongnu.org/msg558389.html Eduardo Habkost (2): virtio: Helper for registering virtio device types virtio: Provide version-specific variants of virtio PCI devices hw/virtio/virtio-pci.h | 78 +++++++-- hw/display/virtio-gpu-pci.c | 7 +- hw/display/virtio-vga.c | 7 +- hw/virtio/virtio-crypto-pci.c | 7 +- hw/virtio/virtio-pci.c | 267 ++++++++++++++++++++++------- tests/acceptance/virtio_version.py | 176 +++++++++++++++++++ 6 files changed, 452 insertions(+), 90 deletions(-) create mode 100644 tests/acceptance/virtio_version.py -- 2.18.0.rc1.1.g3f1ff2140

9 13

[libvirt] [PATCH] libxl: Add support for max_grant_frame setting
by Jim Fehlig 06 Mar '19

06 Mar '19

Xen 4.10 introduced the max_grant_frames xl config setting, which can be set globally in xl.conf(5) or per-domain in xl.cfg(5). max_grant_frames specifies the maximum number of grant frames the domain is allowed to have, which in turn controls the number of pages the domain can share. This patch adds support for setting max_grant_frames on a global level in libxl.conf. Per-domain support via domXML can be provided in a future patch. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- src/libxl/libvirtd_libxl.aug | 2 ++ src/libxl/libxl.conf | 8 ++++++++ src/libxl/libxl_conf.c | 9 +++++++++ src/libxl/libxl_conf.h | 2 ++ src/libxl/test_libvirtd_libxl.aug.in | 1 + 5 files changed, 22 insertions(+) diff --git a/src/libxl/libvirtd_libxl.aug b/src/libxl/libvirtd_libxl.aug index 58b9af3707..1c3e2719fc 100644 --- a/src/libxl/libvirtd_libxl.aug +++ b/src/libxl/libvirtd_libxl.aug @@ -29,6 +29,7 @@ module Libvirtd_libxl = let keepalive_interval_entry = int_entry "keepalive_interval" let keepalive_count_entry = int_entry "keepalive_count" let nested_hvm_entry = bool_entry "nested_hvm" + let max_grant_frames_entry = int_entry "max_grant_frames" (* Each entry in the config is one of the following ... *) let entry = autoballoon_entry @@ -36,6 +37,7 @@ module Libvirtd_libxl = | keepalive_interval_entry | keepalive_count_entry | nested_hvm_entry + | max_grant_frames_entry let comment = [ label "#comment" . del /#[ \t]*/ "# " . store /([^ \t\n][^\n]*)?/ . del /\n/ "\n" ] let empty = [ label "#empty" . eol ] diff --git a/src/libxl/libxl.conf b/src/libxl/libxl.conf index 72825a71c5..12d7abeda6 100644 --- a/src/libxl/libxl.conf +++ b/src/libxl/libxl.conf @@ -49,3 +49,11 @@ # element. # By default it is disabled. #nested_hvm = 0 + +# Xen domains can grant other domains access to its memory pages, which is +# most commonly used for the operation of paravirtualized devices. +# max_grant_frames was introduced in Xen 4.10 and can be used to specify a +# default value for the maximum number of grant frames each domain started +# by libvirt is allowed to have. The default value is 32. +# +#max_grant_frames = 32 diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index c769050ff1..f57ffe1a01 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -393,6 +393,12 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, def->mem.cur_balloon = VIR_ROUND_UP(def->mem.cur_balloon, 1024); b_info->max_memkb = virDomainDefGetMemoryInitial(def); b_info->target_memkb = def->mem.cur_balloon; + +#ifdef LIBXL_HAVE_BUILDINFO_GRANT_LIMITS + if (cfg->max_grant_frames > 0) + b_info->max_grant_frames = cfg->max_grant_frames; +#endif + if (hvm || pvh) { if (caps && def->cpu && def->cpu->mode == (VIR_CPU_MODE_HOST_PASSTHROUGH)) { @@ -1888,6 +1894,9 @@ int libxlDriverConfigLoadFile(libxlDriverConfigPtr cfg, if (virConfGetValueBool(conf, "nested_hvm", &cfg->nested_hvm) < 0) goto cleanup; + if (virConfGetValueUInt(conf, "max_grant_frames", &cfg->max_grant_frames) < 0) + goto cleanup; + ret = 0; cleanup: diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h index fee94241af..985524f3eb 100644 --- a/src/libxl/libxl_conf.h +++ b/src/libxl/libxl_conf.h @@ -86,6 +86,8 @@ struct _libxlDriverConfig { bool nested_hvm; + unsigned int max_grant_frames; + /* Once created, caps are immutable */ virCapsPtr caps; diff --git a/src/libxl/test_libvirtd_libxl.aug.in b/src/libxl/test_libvirtd_libxl.aug.in index 372a43f94a..754ddc10f6 100644 --- a/src/libxl/test_libvirtd_libxl.aug.in +++ b/src/libxl/test_libvirtd_libxl.aug.in @@ -7,3 +7,4 @@ module Test_libvirtd_libxl = { "keepalive_interval" = "5" } { "keepalive_count" = "5" } { "nested_hvm" = "0" } +{ "max_grant_frames" = "32" } -- 2.20.1

2 3

[libvirt] domXML modeling question
by Jim Fehlig 06 Mar '19

06 Mar '19

There have been a few requests [1][2] to support Xen's max_grant_frames setting in libvirt domXML, but I'm not quite sure how to model it. The documentation [3] on this setting states: Specify the maximum number of grant frames the domain is allowed to have. This value controls how many pages the domain is able to grant access to for other domains, needed e.g. for the operation of paravirtualized devices. The default is settable via xl.conf(5). It smells of a <memtune> setting, e.g. the amount of memory a domain can share, but doesn't map to any of the existing settings. A new subelement <shared_limit> doesn't feel right. Does anyone suggest a better way of modeling max_grant_frames? Another option I considered is setting the value based on number of PV devices, but I think that flies in the face of libvirt's policy of not dictating policy. Regardless of domain config modeling I can work on a driver-wide setting in libxl.conf, similar to Xen's xl.conf(5) global. Regards, Jim [1] https://www.redhat.com/archives/libvir-list/2018-April/msg00216.html [2] https://www.redhat.com/archives/libvirt-users/2019-January/msg00011.html [3] http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/man/xl.cfg.5.pod.in;…

3 3

[libvirt] [PATCH 0/4] Couple of patches about virsh completion
by Lin Ma 06 Mar '19

06 Mar '19

Lin Ma (4): virsh: Only return active domain names for detach-device-alias virsh: Add device name completion for target option of detach-disk command virsh-network: Introduce virshNetworkEventCallback to handle network events virsh: Add event name completion to 'network-event' command tools/virsh-completer.c | 27 +++++++++++++++++++++++++++ tools/virsh-completer.h | 4 ++++ tools/virsh-domain.c | 3 ++- tools/virsh-network.c | 18 +++++++++++++++--- tools/virsh-network.h | 8 ++++++++ 5 files changed, 56 insertions(+), 4 deletions(-) -- 2.19.0

2 10

[libvirt] [PATCH v1 00/15] Firmware auto selection
by Michal Privoznik 05 Mar '19

05 Mar '19

Libvirt allows specifying firmware for domains for quite some time now. However, problem for mgmt applications is that they do not know which firmware to chose as all they see are their paths and from that it's impossible to tell whether one of them supports say secure boot. This problem was addressed by qemu where Lazslo and Daniel created a document, specification which describes metadata for each individual firmware image. In the description (which itself is a JSON file for easy machine parsing) then it's specified whether the firmware it's describing supports secureboot, s3/s4 states, it it's bios or efi, and so on. These patches take advantage of that, and even though the description files are not picked up by that many distributions yet, it allows users to not care about putting specific firmware path into their domain XML. It's as easy as: <os firmware='efi'> <loader secure='yes'/> </os> to have libvirt pick up OVMF image with secure enabled boot (and enabled System Management Mode at the same time). The metadata specification lives under qemu.git/docs/interop/firmware.json and I highly recommend you go and read it before reviewing (unless you're Laszlo or Daniel in which case you already know what the document says). As usual, you can find my patches at my github: https://github.com/zippy2/libvirt/commits/firmware_v1 Michal Prívozník (15): virmock: Initialize both symbols in VIR_MOCK_REAL_INIT_ALT qemu_domain: Separate NVRAM VAR store file name generation qemu_capabilities: Expose qemu <-> libvirt arch translators virDomainLoaderDefParseXML: Allow loader path to be NULL conf: Introduce VIR_DOMAIN_LOADER_TYPE_NONE conf: Introduce firmware attribute to <os/> qemu: Introduce basic skeleton for parsing firmware description test: Introduce qemufirmwaretest qemu_firmware: Introduce qemuFirmwareFetchConfigs qemufirmwaretest: Test qemuFirmwareFetchConfigs() qemu_firmware: Introduce qemuFirmwareFillDomain() qemu_process: Call qemuFirmwareFillDomain qemuDomainDefValidate: Don't require SMM if automatic firmware selection enabled qemu: Enable firmware autoselection qemuxml2argvtest: Test os.firmware autoselection docs/formatdomain.html.in | 22 +- docs/schemas/domaincommon.rng | 12 +- src/conf/domain_conf.c | 113 +- src/conf/domain_conf.h | 15 +- src/libvirt_private.syms | 2 + src/qemu/Makefile.inc.am | 2 + src/qemu/qemu_capabilities.c | 4 +- src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 1 + src/qemu/qemu_domain.c | 34 +- src/qemu/qemu_domain.h | 4 + src/qemu/qemu_firmware.c | 1285 +++++++++++++++++ src/qemu/qemu_firmware.h | 50 + src/qemu/qemu_process.c | 5 + tests/Makefile.am | 14 +- tests/domaincapsschemadata/full.xml | 1 + .../etc/qemu/firmware/40-ovmf-sb.json | 1 + .../etc/qemu/firmware/60-ovmf.json | 0 .../user/.config/qemu/firmware/10-bios.json | 0 .../usr/share/qemu/firmware/40-bios.json | 35 + .../usr/share/qemu/firmware/50-ovmf-sb.json | 36 + .../usr/share/qemu/firmware/60-ovmf.json | 35 + .../usr/share/qemu/firmware/70-aavmf.json | 35 + tests/qemufirmwaretest.c | 129 ++ ...arch64-os-firmware-efi.aarch64-latest.args | 37 + .../aarch64-os-firmware-efi.xml | 30 + .../os-firmware-bios.x86_64-latest.args | 39 + tests/qemuxml2argvdata/os-firmware-bios.xml | 68 + ...os-firmware-efi-secboot.x86_64-latest.args | 42 + .../os-firmware-efi-secboot.xml | 68 + .../os-firmware-efi.x86_64-latest.args | 42 + tests/qemuxml2argvdata/os-firmware-efi.xml | 68 + tests/qemuxml2argvtest.c | 17 + .../aarch64-os-firmware-efi.xml | 1 + tests/qemuxml2xmloutdata/os-firmware-bios.xml | 1 + .../os-firmware-efi-secboot.xml | 1 + tests/qemuxml2xmloutdata/os-firmware-efi.xml | 1 + tests/qemuxml2xmltest.c | 27 + tests/virmock.h | 5 +- 39 files changed, 2255 insertions(+), 30 deletions(-) create mode 100644 src/qemu/qemu_firmware.c create mode 100644 src/qemu/qemu_firmware.h create mode 120000 tests/qemufirmwaredata/etc/qemu/firmware/40-ovmf-sb.json create mode 100644 tests/qemufirmwaredata/etc/qemu/firmware/60-ovmf.json create mode 100644 tests/qemufirmwaredata/home/user/.config/qemu/firmware/10-bios.json create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/40-bios.json create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/50-ovmf-sb.json create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/60-ovmf.json create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/70-aavmf.json create mode 100644 tests/qemufirmwaretest.c create mode 100644 tests/qemuxml2argvdata/aarch64-os-firmware-efi.aarch64-latest.args create mode 100644 tests/qemuxml2argvdata/aarch64-os-firmware-efi.xml create mode 100644 tests/qemuxml2argvdata/os-firmware-bios.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/os-firmware-bios.xml create mode 100644 tests/qemuxml2argvdata/os-firmware-efi-secboot.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/os-firmware-efi-secboot.xml create mode 100644 tests/qemuxml2argvdata/os-firmware-efi.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/os-firmware-efi.xml create mode 120000 tests/qemuxml2xmloutdata/aarch64-os-firmware-efi.xml create mode 120000 tests/qemuxml2xmloutdata/os-firmware-bios.xml create mode 120000 tests/qemuxml2xmloutdata/os-firmware-efi-secboot.xml create mode 120000 tests/qemuxml2xmloutdata/os-firmware-efi.xml -- 2.19.2

3 37

[libvirt] [PATCH] docs: Fix version number
by Andrea Bolognani 05 Mar '19

05 Mar '19

virtio-(non-)transitional device models have been introduced in 5.2.0, not 5.1.0. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Pushed as trivial. docs/formatdomain.html.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index f9574f0b24..eb00c01d96 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -4127,7 +4127,7 @@ device when plugged into a PCI Express slot, and like a <code>virtio-transitional</code> device otherwise; libvirt will pick one or the other based on the machine type. This is the best - choice when compatibility with libvirt versions older than 5.1.0 + choice when compatibility with libvirt versions older than 5.2.0 is necessary, but it's otherwise not recommended to use it. </dd> </dl> -- 2.20.1

1 0

[libvirt] [PATCH 0/2] conf: Tweaks to VirtIO SCSI controllers
by Andrea Bolognani 05 Mar '19

05 Mar '19

Patch 2/2 implement a change that was suggested during the review process for the recent virtio-(non-)transitional work but was not considered as blocking for getting the code in, whereas patch 1/2 performs a trivial and hopefully entirely non-controversial enum member rename. Andrea Bolognani (2): conf: Rename VIR_DOMAIN_CONTROLLER_MODEL_SCSI_VIRTIO_SCSI conf: Accept model=virtio for SCSI controllers docs/schemas/domaincommon.rng | 1 + src/conf/domain_conf.c | 18 +++++++++++------- src/conf/domain_conf.h | 2 +- src/qemu/qemu_command.c | 2 +- src/qemu/qemu_domain.c | 6 +++--- src/qemu/qemu_domain_address.c | 6 +++--- src/qemu/qemu_process.c | 2 +- src/vbox/vbox_common.c | 2 +- src/vz/vz_utils.c | 4 ++-- .../controller-virtio-scsi.xml | 2 +- 10 files changed, 25 insertions(+), 20 deletions(-) -- 2.20.1

3 4

[libvirt] [PATCH 0/4] Don't destroy domains on daemon restart and autostarted pools
by Michal Privoznik 05 Mar '19

05 Mar '19

The reverts were not clean. A lot has changed since v1.1.1. Michal Prívozník (4): daemon: Register secret driver before storage driver bhyve: Move autostarting of domains into bhyveStateInitialize Revert "virStateDriver - Separate AutoStart from Initialize" Revert "Separate out StateAutoStart from StateInitialize" src/bhyve/bhyve_driver.c | 12 ++---------- src/driver-state.h | 4 ---- src/libvirt.c | 14 +------------- src/libxl/libxl_driver.c | 14 +++----------- src/lxc/lxc_driver.c | 28 ++++++++-------------------- src/network/bridge_driver.c | 22 ++++------------------ src/qemu/qemu_driver.c | 17 ++--------------- src/remote/remote_daemon.c | 8 ++++---- src/storage/storage_driver.c | 19 ++----------------- 9 files changed, 26 insertions(+), 112 deletions(-) -- 2.19.2

2 8

[libvirt] [PATCH v2 00/30] cpu_x86: Add multiple signatures for CPU models
by Jiri Denemark 05 Mar '19

05 Mar '19

CPU signatures in the cpu_map serve as a hint for CPUID to CPU model matching algorithm. If the CPU signatures matches any CPU model in the cpu_map, this model will be the preferred one. This works out well and solved several mismatches, but in real world CPUs which should match a single CPU model may be produced with several different signatures. For example, low voltage Broadwell CPUs for laptops and Broadwell CPUs for servers differ in CPU model numbers while we should detect them all as Broadwell CPU model. This patch adds support for storing several signatures for a single CPU model to make this hint useful for more CPUs. Later commits will provide additional signatures for existing CPU models, which will correct some results in our CPU test suite. The list of signatures corresponding to each CPU model were generated by consulting the following sites: https://en.wikichip.org/wiki/intel/cpuid http://www.cpu-world.com/cgi-bin/CPUID.pl https://ark.intel.com/content/www/us/en/ark.html Jiri Denemark (30): cputest: Make sure generated files pass syntax-check cputest: Add data for Intel(R) Xeon(R) CPU E5-2630 v4 cputest: Add data for Intel(R) Core(TM) i7-7600U cputest: Add data for Intel(R) Xeon(R) CPU E7540 cputest: Add data for Intel(R) Xeon(R) CPU E5-2650 cputest: Add data for Intel(R) Core(TM) i7-8700 cpu_x86: Separate ancestor model parsing from x86ModelParse cpu_x86: Separate signature parsing from x86ModelParse cpu_x86: Separate vendor parsing from x86ModelParse cpu_x86: Separate feature list parsing from x86ModelParse cpu_x86: Make sure CPU model names are unique in cpu_map cpu_x86: Add x86ModelCopySignatures helper cpu_x86: Store CPU signature in an array cpu_x86: Allow multiple signatures for a CPU model cpu_x86: Log decoded CPU model and signatures qemu_capabilities: Inroduce virQEMUCapsGetCPUModelX86Data qemu_capabilities: Introduce virQEMUCapsGetCPUModelInfo qemu_capabilities: Use virQEMUCapsGetCPUModelInfo cpu_x86: Add virCPUx86DataGetSignature for tests cpu_map: Add hex representation of signatures cputest: Test CPU signatures cpu_map: Add more signatures for Conroe CPU model cpu_map: Add more signatures for Penryn CPU model cpu_map: Add more signatures for Nehalem CPU models cpu_map: Add more signatures for Westmere CPU model cpu_map: Add more signatures for SandyBridge CPU models cpu_map: Add more signatures for IvyBridge CPU models cpu_map: Add more signatures for Haswell CPU models cpu_map: Add more signatures for Broadwell CPU models cpu_map: Add more signatures for Skylake-Client CPU models src/cpu/cpu_x86.c | 357 ++++-- src/cpu/cpu_x86.h | 5 + src/cpu_map/x86_Broadwell-IBRS.xml | 5 +- src/cpu_map/x86_Broadwell-noTSX-IBRS.xml | 5 +- src/cpu_map/x86_Broadwell-noTSX.xml | 5 +- src/cpu_map/x86_Broadwell.xml | 5 +- src/cpu_map/x86_Conroe.xml | 3 +- src/cpu_map/x86_EPYC-IBRS.xml | 2 +- src/cpu_map/x86_EPYC.xml | 2 +- src/cpu_map/x86_Haswell-IBRS.xml | 5 +- src/cpu_map/x86_Haswell-noTSX-IBRS.xml | 5 +- src/cpu_map/x86_Haswell-noTSX.xml | 5 +- src/cpu_map/x86_Haswell.xml | 5 +- src/cpu_map/x86_Icelake-Client.xml | 2 +- src/cpu_map/x86_Icelake-Server.xml | 2 +- src/cpu_map/x86_IvyBridge-IBRS.xml | 3 +- src/cpu_map/x86_IvyBridge.xml | 3 +- src/cpu_map/x86_Nehalem-IBRS.xml | 5 +- src/cpu_map/x86_Nehalem.xml | 5 +- src/cpu_map/x86_Opteron_G1.xml | 2 +- src/cpu_map/x86_Opteron_G2.xml | 2 +- src/cpu_map/x86_Opteron_G3.xml | 2 +- src/cpu_map/x86_Opteron_G4.xml | 2 +- src/cpu_map/x86_Opteron_G5.xml | 2 +- src/cpu_map/x86_Penryn.xml | 3 +- src/cpu_map/x86_SandyBridge-IBRS.xml | 3 +- src/cpu_map/x86_SandyBridge.xml | 3 +- src/cpu_map/x86_Skylake-Client-IBRS.xml | 7 +- src/cpu_map/x86_Skylake-Client.xml | 7 +- src/cpu_map/x86_Skylake-Server-IBRS.xml | 2 +- src/cpu_map/x86_Skylake-Server.xml | 2 +- src/cpu_map/x86_Westmere-IBRS.xml | 2 +- src/cpu_map/x86_Westmere.xml | 4 +- src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 91 +- src/qemu/qemu_capspriv.h | 8 + tests/cputest.c | 91 ++ tests/cputestdata/cpu-reformat.py | 2 +- tests/cputestdata/x86_64-cpuid-A10-5800K.sig | 4 + tests/cputestdata/x86_64-cpuid-Atom-D510.sig | 4 + tests/cputestdata/x86_64-cpuid-Atom-N450.sig | 4 + .../cputestdata/x86_64-cpuid-Core-i5-2500.sig | 4 + .../x86_64-cpuid-Core-i5-2540M.sig | 4 + .../x86_64-cpuid-Core-i5-4670T.sig | 4 + .../x86_64-cpuid-Core-i5-650-json.xml | 9 +- .../cputestdata/x86_64-cpuid-Core-i5-650.sig | 4 + .../cputestdata/x86_64-cpuid-Core-i5-6600.sig | 4 + .../x86_64-cpuid-Core-i7-2600-xsaveopt.sig | 4 + .../cputestdata/x86_64-cpuid-Core-i7-2600.sig | 4 + .../x86_64-cpuid-Core-i7-3520M.sig | 4 + .../x86_64-cpuid-Core-i7-3740QM.sig | 4 + .../cputestdata/x86_64-cpuid-Core-i7-3770.sig | 4 + .../x86_64-cpuid-Core-i7-4510U.sig | 4 + .../x86_64-cpuid-Core-i7-4600U.sig | 4 + .../x86_64-cpuid-Core-i7-5600U-arat.sig | 4 + .../x86_64-cpuid-Core-i7-5600U-ibrs.sig | 4 + .../x86_64-cpuid-Core-i7-5600U.sig | 4 + .../x86_64-cpuid-Core-i7-7600U-disabled.xml | 6 + .../x86_64-cpuid-Core-i7-7600U-enabled.xml | 8 + .../x86_64-cpuid-Core-i7-7600U-guest.xml | 28 + .../x86_64-cpuid-Core-i7-7600U-host.xml | 29 + .../x86_64-cpuid-Core-i7-7600U-json.xml | 13 + .../x86_64-cpuid-Core-i7-7600U.json | 755 +++++++++++ .../x86_64-cpuid-Core-i7-7600U.sig | 4 + .../x86_64-cpuid-Core-i7-7600U.xml | 47 + .../cputestdata/x86_64-cpuid-Core-i7-7700.sig | 4 + .../x86_64-cpuid-Core-i7-8700-disabled.xml | 6 + .../x86_64-cpuid-Core-i7-8700-enabled.xml | 8 + .../x86_64-cpuid-Core-i7-8700-guest.xml | 28 + .../x86_64-cpuid-Core-i7-8700-host.xml | 29 + .../x86_64-cpuid-Core-i7-8700-json.xml | 12 + .../x86_64-cpuid-Core-i7-8700.json | 650 ++++++++++ .../cputestdata/x86_64-cpuid-Core-i7-8700.sig | 4 + .../cputestdata/x86_64-cpuid-Core-i7-8700.xml | 47 + .../cputestdata/x86_64-cpuid-Core2-E6850.sig | 4 + .../cputestdata/x86_64-cpuid-Core2-Q9500.sig | 4 + .../x86_64-cpuid-EPYC-7601-32-Core-ibpb.sig | 4 + .../x86_64-cpuid-EPYC-7601-32-Core.sig | 4 + tests/cputestdata/x86_64-cpuid-FX-8150.sig | 4 + .../cputestdata/x86_64-cpuid-Opteron-1352.sig | 4 + .../cputestdata/x86_64-cpuid-Opteron-2350.sig | 4 + .../cputestdata/x86_64-cpuid-Opteron-6234.sig | 4 + .../cputestdata/x86_64-cpuid-Opteron-6282.sig | 4 + .../x86_64-cpuid-Pentium-P6100-guest.xml | 10 +- .../x86_64-cpuid-Pentium-P6100.sig | 4 + tests/cputestdata/x86_64-cpuid-Phenom-B95.sig | 4 + .../x86_64-cpuid-Ryzen-7-1800X-Eight-Core.sig | 4 + tests/cputestdata/x86_64-cpuid-Xeon-5110.sig | 4 + .../x86_64-cpuid-Xeon-E3-1245-v5.sig | 4 + .../x86_64-cpuid-Xeon-E5-2609-v3.sig | 4 + .../x86_64-cpuid-Xeon-E5-2623-v4-guest.xml | 11 +- .../x86_64-cpuid-Xeon-E5-2623-v4-json.xml | 11 +- .../x86_64-cpuid-Xeon-E5-2623-v4.sig | 4 + .../x86_64-cpuid-Xeon-E5-2630-v3.sig | 4 + .../x86_64-cpuid-Xeon-E5-2630-v4-disabled.xml | 7 + .../x86_64-cpuid-Xeon-E5-2630-v4-enabled.xml | 8 + .../x86_64-cpuid-Xeon-E5-2630-v4-guest.xml | 34 + .../x86_64-cpuid-Xeon-E5-2630-v4-host.xml | 35 + .../x86_64-cpuid-Xeon-E5-2630-v4-json.xml | 14 + .../x86_64-cpuid-Xeon-E5-2630-v4.json | 596 +++++++++ .../x86_64-cpuid-Xeon-E5-2630-v4.sig | 4 + .../x86_64-cpuid-Xeon-E5-2630-v4.xml | 43 + .../x86_64-cpuid-Xeon-E5-2650-disabled.xml | 5 + .../x86_64-cpuid-Xeon-E5-2650-enabled.xml | 8 + .../x86_64-cpuid-Xeon-E5-2650-guest.xml | 29 + .../x86_64-cpuid-Xeon-E5-2650-host.xml | 30 + .../x86_64-cpuid-Xeon-E5-2650-json.xml | 14 + .../x86_64-cpuid-Xeon-E5-2650-v3.sig | 4 + .../x86_64-cpuid-Xeon-E5-2650-v4-guest.xml | 11 +- .../x86_64-cpuid-Xeon-E5-2650-v4-json.xml | 11 +- .../x86_64-cpuid-Xeon-E5-2650-v4.sig | 4 + .../x86_64-cpuid-Xeon-E5-2650.json | 931 ++++++++++++++ .../cputestdata/x86_64-cpuid-Xeon-E5-2650.sig | 4 + .../cputestdata/x86_64-cpuid-Xeon-E5-2650.xml | 34 + .../x86_64-cpuid-Xeon-E7-4820-guest.xml | 8 +- .../x86_64-cpuid-Xeon-E7-4820-json.xml | 8 +- .../cputestdata/x86_64-cpuid-Xeon-E7-4820.sig | 4 + .../x86_64-cpuid-Xeon-E7-4830-json.xml | 9 +- .../cputestdata/x86_64-cpuid-Xeon-E7-4830.sig | 4 + .../x86_64-cpuid-Xeon-E7-8890-v3.sig | 4 + .../x86_64-cpuid-Xeon-E7540-disabled.xml | 5 + .../x86_64-cpuid-Xeon-E7540-enabled.xml | 7 + .../x86_64-cpuid-Xeon-E7540-guest.xml | 25 + .../x86_64-cpuid-Xeon-E7540-host.xml | 26 + .../x86_64-cpuid-Xeon-E7540-json.xml | 14 + .../cputestdata/x86_64-cpuid-Xeon-E7540.json | 1117 +++++++++++++++++ tests/cputestdata/x86_64-cpuid-Xeon-E7540.sig | 4 + tests/cputestdata/x86_64-cpuid-Xeon-E7540.xml | 30 + .../x86_64-cpuid-Xeon-Gold-5115.sig | 4 + .../x86_64-cpuid-Xeon-Gold-6148.sig | 4 + tests/cputestdata/x86_64-cpuid-Xeon-W3520.sig | 4 + tests/cputestdata/x86_64-cpuid-Xeon-X5460.sig | 4 + 132 files changed, 5425 insertions(+), 206 deletions(-) create mode 100644 tests/cputestdata/x86_64-cpuid-A10-5800K.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Atom-D510.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Atom-N450.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i5-2500.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i5-2540M.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i5-4670T.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i5-650.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i5-6600.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-3520M.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-3740QM.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-3770.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-4510U.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-4600U.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-5600U-arat.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-5600U-ibrs.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-5600U.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7600U-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7600U-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7600U-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7600U-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7600U-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7600U.json create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7600U.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7600U.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7700.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-8700-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-8700-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-8700-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-8700-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-8700-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-8700.json create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-8700.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-8700.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core2-E6850.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core2-Q9500.sig create mode 100644 tests/cputestdata/x86_64-cpuid-EPYC-7601-32-Core-ibpb.sig create mode 100644 tests/cputestdata/x86_64-cpuid-EPYC-7601-32-Core.sig create mode 100644 tests/cputestdata/x86_64-cpuid-FX-8150.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Opteron-1352.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Opteron-2350.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Opteron-6234.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Opteron-6282.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Pentium-P6100.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Phenom-B95.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Ryzen-7-1800X-Eight-Core.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-5110.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E3-1245-v5.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2609-v3.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2623-v4.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v3.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v4-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v4-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v4-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v4-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v4-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v4.json create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v4.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v4.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v3.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v4.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650.json create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4820.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-8890-v3.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7540-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7540-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7540-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7540-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7540-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7540.json create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7540.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7540.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-Gold-5115.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-Gold-6148.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-W3520.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-X5460.sig -- 2.21.0

2 36

[libvirt] [PATCH] Fix the recent CI build failures
by Erik Skultety 05 Mar '19

05 Mar '19

After commits e2087c2 and ec0793de older GCC started act very smart and complain about potentially uninitialized variable, which existed prior to these patches + even if the affected vars were left uninitialized the function responsible for filling them in would have failed with NULL being returned which the caller has always handled carefully. Although GCC complained only about a single variable, let's initialize all of them so as to prevent any further potential breakages. Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- Pushed under the build breaker rule. src/conf/domain_conf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index bfafac407e..d84cc2d482 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -18400,9 +18400,9 @@ virDomainThreadSchedParseHelper(xmlNodePtr node, virDomainDefPtr def) { ssize_t next = -1; - virDomainThreadSchedParamPtr sched; - virProcessSchedPolicy policy; - int priority; + virDomainThreadSchedParamPtr sched = NULL; + virProcessSchedPolicy policy = 0; + int priority = 0; VIR_AUTOPTR(virBitmap) map = NULL; if (!(map = virDomainSchedulerParse(node, name, &policy, &priority))) -- 2.20.1

2 1

[libvirt] [PATCH 0/3] tests: Clean up qemuxml2xml a bit
by Andrea Bolognani 05 Mar '19

05 Mar '19

Just your average yak shaving, really. Andrea Bolognani (3): tests: Rename some qemuxml2xml output files for clarity tests: Use WHEN_BOTH in qemuxml2xml whenever possible tests: Add -inactive suffix when appropriate for qemuxml2xml ...ml => channel-unix-source-path-active.xml} | 3 + ... => channel-unix-source-path-inactive.xml} | 0 ...mmit.xml => disk-active-commit-active.xml} | 0 ...it.xml => disk-active-commit-inactive.xml} | 8 +- .../disk-backing-chains-noindex-inactive.xml | 156 ------------------ ...ve.xml => disk-backing-chains-noindex.xml} | 0 ...ror-old.xml => disk-mirror-old-active.xml} | 0 ...> seclabel-dynamic-baselabel-inactive.xml} | 0 ...> seclabel-dynamic-labelskip-inactive.xml} | 0 ...eclabel-dynamic-none-relabel-inactive.xml} | 0 ...=> seclabel-dynamic-override-inactive.xml} | 0 ... => seclabel-dynamic-relabel-inactive.xml} | 0 ...l => seclabel-static-labelskip-active.xml} | 0 ...=> seclabel-static-labelskip-inactive.xml} | 5 +- tests/qemuxml2xmltest.c | 6 +- 15 files changed, 11 insertions(+), 167 deletions(-) copy tests/qemuxml2xmloutdata/{channel-unix-source-path.xml => channel-unix-source-path-active.xml} (86%) rename tests/qemuxml2xmloutdata/{channel-unix-source-path.xml => channel-unix-source-path-inactive.xml} (100%) copy tests/qemuxml2xmloutdata/{disk-active-commit.xml => disk-active-commit-active.xml} (100%) rename tests/qemuxml2xmloutdata/{disk-active-commit.xml => disk-active-commit-inactive.xml} (86%) delete mode 100644 tests/qemuxml2xmloutdata/disk-backing-chains-noindex-inactive.xml rename tests/qemuxml2xmloutdata/{disk-backing-chains-noindex-active.xml => disk-backing-chains-noindex.xml} (100%) rename tests/qemuxml2xmloutdata/{disk-mirror-old.xml => disk-mirror-old-active.xml} (100%) rename tests/qemuxml2xmloutdata/{seclabel-dynamic-baselabel.xml => seclabel-dynamic-baselabel-inactive.xml} (100%) copy tests/qemuxml2xmloutdata/{seclabel-dynamic-labelskip.xml => seclabel-dynamic-labelskip-inactive.xml} (100%) rename tests/qemuxml2xmloutdata/{seclabel-dynamic-none-relabel.xml => seclabel-dynamic-none-relabel-inactive.xml} (100%) rename tests/qemuxml2xmloutdata/{seclabel-dynamic-override.xml => seclabel-dynamic-override-inactive.xml} (100%) rename tests/qemuxml2xmloutdata/{seclabel-dynamic-relabel.xml => seclabel-dynamic-relabel-inactive.xml} (100%) rename tests/qemuxml2xmloutdata/{seclabel-static-labelskip.xml => seclabel-static-labelskip-active.xml} (100%) rename tests/qemuxml2xmloutdata/{seclabel-dynamic-labelskip.xml => seclabel-static-labelskip-inactive.xml} (90%) -- 2.20.1

2 8

[libvirt] [PATCH 0/6] lxc: Add suport to network indexes for LXC 3.X.
by Julio Faracco 04 Mar '19

04 Mar '19

This series implement support for network syntax settings for LXC 3.X. Now, indexes are part of the settings to define network interfaces. Each interface has its own index. The old style uses 'type' tag to differentiate each interface. Old: lxc.network.type = veth lxc.network.flags = up lxc.network.link = virbr0 New: lxc.net.0.type = veth lxc.net.0.flags = up lxc.net.0.link = virbr0 Julio Faracco (6): lxc: Rebase lxcNetworkParseData struct to support indexes. lxc: Rebase lxcNetworkParseData pointers to use new structures. lxc: Introduce lxcNetworkGetParseDataLegacy() method. lxc: Introduce lxcNetworkGetParseData() for 'lxc.net.' entry. tests: Change network settings of V3 testcase set. tests: Introduce random network settings to test indexes. src/lxc/lxc_native.c | 192 ++++++++++++------ .../lxcconf2xml-ethernet-v3.config | 16 +- .../lxcconf2xml-fstab-v3.config | 10 +- .../lxcconf2xml-macvlannetwork-v3.config | 10 +- .../lxcconf2xml-miscnetwork-v3.config | 38 ++-- .../lxcconf2xml-nonenetwork-v3.config | 2 +- .../lxcconf2xml-physnetwork-v3.config | 14 +- .../lxcconf2xml-randomnetwork-v3.config | 21 ++ .../lxcconf2xml-randomnetwork.xml | 45 ++++ .../lxcconf2xml-simple-v3.config | 18 +- .../lxcconf2xmldata/lxcconf2xml-simple.config | 18 +- .../lxcconf2xml-vlannetwork-v3.config | 10 +- tests/lxcconf2xmltest.c | 1 + 13 files changed, 268 insertions(+), 127 deletions(-) create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-randomnetwork-v3.config create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-randomnetwork.xml -- 2.19.1

1 6

[libvirt] [PATCH v2 0/3] PPC64 support for NVIDIA V100 GPU with NVLink2 passthrough
by Daniel Henrique Barboza 04 Mar '19

04 Mar '19

This series includes Libvirt support for a new QEMU feature for the spapr (PPC64) machine, NVIDIA V100 + P9 passthrough. Refer to [1] for the version 3 of this feature (same version used as a reference for this series). v2 has a entirely different approach from the first patch [2] that simply grants IPC_LOCK to the QEMU process: - first patch is a cleanup to make it easier to insert additional logic in the code - patch 2 contains helper functions that browses the device tree at /proc/device-tree to detect if a given VFIO PCI device is using a NVLink2 bus - patch 3 includes the passthroughLimit calculation for PPC64 guests that are using NVLink2 passthrough GPUs. [1] https://patchwork.kernel.org/cover/10831413/ [2] https://www.redhat.com/archives/libvir-list/2019-February/msg00219.html Daniel Henrique Barboza (3): qemu_domain: simplify non-VFIO memLockLimit calc for PPC64 qemu_domain: NVLink2 device tree functions for PPC64 PPC64 support for NVIDIA V100 GPU with NVLink2 passthrough src/qemu/qemu_domain.c | 245 +++++++++++++++++++++++++++++++++++++++-- 1 file changed, 234 insertions(+), 11 deletions(-) -- 2.20.1

3 11

[libvirt] [PATCH] virDomainDiskTranslateSourcePool: Don't set @mode of iscsi-direct
by Michal Privoznik 04 Mar '19

04 Mar '19

https://bugzilla.redhat.com/show_bug.cgi?id=1658504 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/conf/domain_conf.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 05c2c9f34e..3340f0b0ef 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -30565,8 +30565,6 @@ virDomainDiskTranslateSourcePool(virDomainDiskDefPtr def) return -1; } - def->src->srcpool->mode = VIR_STORAGE_SOURCE_POOL_MODE_DIRECT; - if (virDomainDiskTranslateISCSIDirect(def, pooldef) < 0) return -1; -- 2.19.2

2 2

[libvirt] [PATCH v3 00/10] Alter domain_conf to make use of autofree
by John Ferlan 04 Mar '19

04 Mar '19

v2: https://www.redhat.com/archives/libvir-list/2019-February/msg01201.html Changes since v2: Patches 1-5 are marked w/ reviewed-by Added patch 6 to add a few more VIR_AUTOFREE on char *'s that I missed in the first passes - these would be merged with previous after a successful review. Added patch 7 to add VIR_AUTOUNREF. Patch 8 is unchanged from previous patch 6 Patch 9 is more places where cleanup could occur from code review and from the VIR_AUTOUNREF change Patch 10 is a change to virDomainKeyWrapDefParseXML as requested as part of the code review Other requests for more VIR_AUTOPTR usage should be done right and at a later point. Usage of VIR_XPATH_NODE_AUTORESTORE would also have to wait since those changes aren't pushed yet, but that could lead to *a lot* more cleanup in domain_conf. John Ferlan (10): conf: Rework virDomainEmulatorPinDefParseXML conf: Use VIR_AUTOPTR(virBitmap) in domain_conf conf: Clean up some unnecessary goto paths conf: Remove a few unused variables in domain_conf conf: Use VIR_AUTOFREE in domain_conf conf: Merge with previous conf: Use VIR_AUTOUNREF in domain_conf conf: Clean up some unnecessary goto paths conf: Merge with previous conf: Rework virDomainKeyWrapDefParseXML src/conf/domain_conf.c | 2080 ++++++++++++++-------------------------- 1 file changed, 731 insertions(+), 1349 deletions(-) -- 2.20.1

3 21

[libvirt] [PATCH] maint: Post-release version bump to 5.1.0
by Peter Krempa 04 Mar '19

04 Mar '19

Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- configure.ac | 2 +- docs/news.xml | 8 ++++++++ 2 files changed, 9 insertions(+), 1 deletion(-) Pushed under the trivial rule. P.S.: I noticed I didn't fix the version in the summary I've copy-pasted after pushing ... diff --git a/configure.ac b/configure.ac index 4dcdd12069..197d9746b2 100644 --- a/configure.ac +++ b/configure.ac @@ -16,7 +16,7 @@ dnl You should have received a copy of the GNU Lesser General Public dnl License along with this library. If not, see dnl <http://www.gnu.org/licenses/>. -AC_INIT([libvirt], [5.1.0], [libvir-list(a)redhat.com] [], [https://libvirt.org] +AC_INIT([libvirt], [5.2.0], [libvir-list(a)redhat.com] [], [https://libvirt.org] AC_CONFIG_SRCDIR([src/libvirt.c]) AC_CONFIG_AUX_DIR([build-aux]) AC_CONFIG_HEADERS([config.h]) diff --git a/docs/news.xml b/docs/news.xml index e8d2c46457..7483631cd8 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -33,6 +33,14 @@ --> <libvirt> + <release version="v5.2.0" date="unreleased"> + <section title="New features"> + </section> + <section title="Improvements"> + </section> + <section title="Bug fixes"> + </section> + </release> <release version="v5.1.0" date="2019-03-04"> <section title="New features"> <change> -- 2.20.1

1 0

[libvirt] Release of libvirt-5.1.0
by Daniel Veillard 04 Mar '19

04 Mar '19

A few days late after some travel, but everything is now pushed, freeze is over ! The release is tagged in git, signed tarball and rpms are available from the usual place: ftp://libvirt.org/libvirt/ I also pushed the Python bindings release at: ftp://libvirt.org/libvirt/python/ This is a rather large release, with a fair amount of new features, improvement and bug fixes: New features: - bhyve: Add support for additional command-line arguments The bhyve driver now supports passing additional command-line arguments to the bhyve process using the new <bhyve:commandline> element in domain configuration. - network: Support setting a firewalld "zone" for virtual network bridges All libvirt virtual networks with bridges managed by libvirt (i.e. those with forward mode of "nat", "route", "open", or no forward mode) will now be placed in a special firewalld zone called "libvirt" by default. The zone of any network bridge can be changed using the zone attribute of the network's bridge element. - bhyve: Support for ignoring unknown MSRs reads and writes A new <features> element <msrs unknown='ignore'/> was introduced and the bhyve driver supports it to control unknown Model Specific Registers (MSRs) reads and writes. - qemu: Add support for encrypted VNC TLS keys Use the password stored in the secret driver under the uuid specified by the vnc_tls_x509_secret_uuid option in qemu.conf. - Add storage pool namespace options Allow for adjustment of RBD configuration options via Storage Pool XML Namespace adjustments. - qemu: Add support for setting post-copy migration bandwidth Users can now limit the bandwidth of post-copy migration, e.g. via virsh migrate --postcopy-bandwidth. Improvements: - Create private chains for virtual network firewall rules Historically firewall rules for virtual networks were added straight into the base chains. This works but has a number of bugs and design limitations. To address them, libvirt now puts firewall rules into its own chains. - Detect CEPH and GPFS as shared FS When starting a migration libvirt performs some sanity checks to make sure domain will be able to run on the destination. One of the requirements is that the disk has to either be migrated too or be accessible from a network filesystem. CEPH and GPFS weren't detected as a network filesystem. - Advertise network MTU via DHCP when specified If network MTU is set and the network has DHCP enabled, advertise the MTU in DHCP transaction too so that clients can adjust their link accordingly. - qemu: Allocate memory at the configured NUMA nodes from start Libvirt used to just start QEMU, let it allocate memory for the guest, and then use CGroups to move the memory to configured NUMA nodes. This is suboptimal as huge chunks of memory have to be moved. Moreover, this relies on ability to move memory later which is not always true. A change was made to set process affinity correctly from the start so that memory is allocated on the configured nodes from the beginning. - Support for newer Wireshark Adapt libvirt to use the more recent release requiring a source build configuration of libvirt --with-wireshark to upgrade to the more recent version. - Batch mode virsh and virt-admin parsing improvements When parsing a single-argument command_string in batch mode, virsh and virt-admin now permit newlines in addition to semicolons for splitting commands, and backslash-newline for splitting long lines, to be more like shell parsing. Bug fixes: - qemu: Use CAP_DAC_OVERRIDE during QEMU capabilities probing By default, libvirt runs the QEMU process as qemu:qemu which could cause issues during probing as some features like AMD SEV might be inaccessible to QEMU because of file system permissions. Therefore, CAP_DAC_OVERRIDE is granted to overcome these for the purposes of probing. - storage: Add default mount options for fs/netfs storage pools Altered the command line generation for fs/netfs storage pools to add some default options. For Linux based systems, the options added are "nodev, nosuid, noexec". For FreeBSD based systems, the options added are "nosuid, noexec". - qemu: Allow use of PCI for RISC-V guests This works with QEMU 4.0.0+ only and is opt-in at the moment, since it requires users to manually assign PCI addresses, but is otherwise fully functional. - network: Fix virtual networks on systems using firewalld+nftables Because of the transitional state of firewalld's new support for nftables, not all iptables features required by libvirt are yet available, so libvirt must continue to use iptables for its own packet filtering rules even when the firewalld backend is set to use nftables. However, due to the way iptables support is implemented in kernels using nftables (iptables rules are converted to nftables rules and processed in a separate hook from the native nftables rules), guest networking was broken on hosts with firewalld configured to use nftables as the backend. This has been fixed by putting libvirt-managed bridges in their own firewalld zone, so that guest traffic can be forwarded beyond the host and host services can be exposed to guests on the virtual network without opening up those same services to the rest of the physical network. This means that host access from virtual machines is no longer controlled by the firewalld default zone (usually "public"), but rather by the new firewalld zone called "libvirt" (unless configured otherwise using the new zone attribute of the network bridge element). - qemu: Fix i6300esb watchdog hotplug on Q35 Ensure that libvirt allocates a PCI address for the device so that QEMU did not default to an address that would not allow for device hotplug. - lxc: Don't reboot host on virDomainReboot If the container is really a simple one (init is just bash and the whole root is passed through) then virDomainReboot and virDomainShutdown would reboot or shutdown the host. The solution is to use different method to reboot or shutdown the container in that case (e.g. signal). - rpc: Various stream fixes One particular race was fixed, one locking problem and error reporting from streams was made better. - qemu: Fix guestfwd hotplug/hotunplug Fixed the generation of the guestfwd hotplug/unplug command sent to QEMU to match the syntax used when creating the initial command line. - qemu: Forbid CDROMs on virtio bus Attempting to create an empty virtio-blk drive or attempting to eject it results into an error. Forbid configurations where users would attempt to use CDROMs in virtio bus. - qemu: Use 'raw' for 'volume' disks without format Storage pools might want to specify format of the image when translating the volume thus libvirt can't add any default format when parsing the XML. Add an explicit format when starting the VM and format is not present neither by user specifying it nor by the storage pool translation function. - qemu: Assume 'raw' default storage format also for network storage Post parse callback adds the 'raw' type only for local files. Remote files can also have backing store (even local) so we should do this also for network backed storage. - qemu: Fix block job progress reporting and advocate for READY event In some cases QEMU can get to 100% and still not reach the synchronised phase. Initiating a pivot in that case will fail. Therefore it is strongly advised to wait for VIR_DOMAIN_BLOCK_JOB_READY event which does not suffer from this problem. - qemu: Don't format image properties for empty drive If a -drive has no image, then formatting attributes such as cache, readonly, etc. would cause errors to be reported from QEMU. This was fixed by not supplying the attributes for devices without an image. - External snapshot metadata redefinition is fixed Attempting to use VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE to reinstate the metadata describing an external snapshot created earlier for an offline domain no longer fails. Thanks everybody for your contributions to this new release, enjoy ! Daniel -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

1 0

[libvirt] [jenkins-ci PATCH v6 0/4] Add support for cross compiling libvirt via Debian
by Daniel P. Berrangé 01 Mar '19

01 Mar '19

Changed in v6: - Use a static mapping for arch info - Split out data file changes from code changes - Change arch suffix to a prefix Changed in v5: - Remove redundant formatter class - Update commit message - Update readme - Move misplaced patch chunk - Dont set "dest" in arg when not needed - Use metavar for subparser Changed in v4: - Pull in change to use argparse sub-parsers - Refactor way architecture specific package rules are stored to be in the main package mappings data Changed in v3: - Remove sheepdog more generally - Use .format() style printf - Split config to cross-build.yml - Make glusterfs name per-distro customized - Misc code style changes - Rename fields in cross-build.yml - Don't use crossbuild-essential packages Changed in v2: - Fix multiple package name mistakes - Modify lcitool to generate cross-arch docker files - Add --no-install-recommended flag to apt-get - Add DEBIAN_FRONTEND=noninteractive env to apt-get - Improve error reporting in lcitool - Add make rule for generating dockerfiles locally Daniel P. Berrangé (4): mappings: extend mapping to allow per-arch entries mappings: filter arch usage for libnuma / xen lcitool: support generating cross compiler dockerfiles mappings: mark packages using foreign arch for cross builds guests/lcitool | 117 ++++++++++++++++++++- guests/playbooks/update/tasks/packages.yml | 32 ++++++ guests/vars/mappings.yml | 106 ++++++++++++++++++- 3 files changed, 249 insertions(+), 6 deletions(-) -- 2.20.1

2 10

[libvirt] [PATCH 00/26] cpu_x86: Add multiple signatures for CPU models
by Jiri Denemark 01 Mar '19

01 Mar '19

CPU signatures in the cpu_map serve as a hint for CPUID to CPU model matching algorithm. If the CPU signatures matches any CPU model in the cpu_map, this model will be the preferred one. This works out well and solved several mismatches, but in real world CPUs which should match a single CPU model may be produced with several different signatures. For example, low voltage Broadwell CPUs for laptops and Broadwell CPUs for servers differ in CPU model numbers while we should detect them all as Broadwell CPU model. This patch adds support for storing several signatures for a single CPU model to make this hint useful for more CPUs. Later commits will provide additional signatures for existing CPU models, which will correct some results in our CPU test suite. The list of signatures corresponding to each CPU model were generated by consulting the following sites: https://en.wikichip.org/wiki/intel/cpuid http://www.cpu-world.com/cgi-bin/CPUID.pl https://ark.intel.com/content/www/us/en/ark.html Jiri Denemark (26): cputest: Make sure generated files pass syntax-check cputest: Add data for Intel(R) Xeon(R) CPU E5-2630 v4 cputest: Add data for Intel(R) Core(TM) i7-7600U cputest: Add data for Intel(R) Xeon(R) CPU E7540 cputest: Add data for Intel(R) Xeon(R) CPU E5-2650 cpu_x86: Separate ancestor model parsing from x86ModelParse cpu_x86: Separate signature parsing from x86ModelParse cpu_x86: Separate vendor parsing from x86ModelParse cpu_x86: Separate feature list parsing from x86ModelParse cpu_x86: Make sure CPU model names are unique in cpu_map cpu_x86: Allow multiple signatures for a CPU model qemu_capabilities: Inroduce virQEMUCapsGetCPUModelX86Data qemu_capabilities: Introduce virQEMUCapsGetCPUModelInfo qemu_capabilities: Use virQEMUCapsGetCPUModelInfo cpu_x86: Add virCPUx86DataGetSignature for tests cpu_map: Add hex representation of signatures cputest: Test CPU signatures cpu_map: Add more signatures for Conroe CPU model cpu_map: Add more signatures for Penryn CPU model cpu_map: Add more signatures for Nehalem CPU models cpu_map: Add more signatures for Westmere CPU model cpu_map: Add more signatures for SandyBridge CPU models cpu_map: Add more signatures for IvyBridge CPU models cpu_map: Add more signatures for Haswell CPU models cpu_map: Add more signatures for Broadwell CPU models cpu_map: Add more signatures for Skylake-Client CPU models src/cpu/cpu_x86.c | 345 +++-- src/cpu/cpu_x86.h | 5 + src/cpu_map/x86_Broadwell-IBRS.xml | 5 +- src/cpu_map/x86_Broadwell-noTSX-IBRS.xml | 5 +- src/cpu_map/x86_Broadwell-noTSX.xml | 5 +- src/cpu_map/x86_Broadwell.xml | 5 +- src/cpu_map/x86_Conroe.xml | 3 +- src/cpu_map/x86_EPYC-IBRS.xml | 2 +- src/cpu_map/x86_EPYC.xml | 2 +- src/cpu_map/x86_Haswell-IBRS.xml | 5 +- src/cpu_map/x86_Haswell-noTSX-IBRS.xml | 5 +- src/cpu_map/x86_Haswell-noTSX.xml | 5 +- src/cpu_map/x86_Haswell.xml | 5 +- src/cpu_map/x86_Icelake-Client.xml | 2 +- src/cpu_map/x86_Icelake-Server.xml | 2 +- src/cpu_map/x86_IvyBridge-IBRS.xml | 3 +- src/cpu_map/x86_IvyBridge.xml | 3 +- src/cpu_map/x86_Nehalem-IBRS.xml | 5 +- src/cpu_map/x86_Nehalem.xml | 5 +- src/cpu_map/x86_Opteron_G1.xml | 2 +- src/cpu_map/x86_Opteron_G2.xml | 2 +- src/cpu_map/x86_Opteron_G3.xml | 2 +- src/cpu_map/x86_Opteron_G4.xml | 2 +- src/cpu_map/x86_Opteron_G5.xml | 2 +- src/cpu_map/x86_Penryn.xml | 3 +- src/cpu_map/x86_SandyBridge-IBRS.xml | 3 +- src/cpu_map/x86_SandyBridge.xml | 3 +- src/cpu_map/x86_Skylake-Client-IBRS.xml | 7 +- src/cpu_map/x86_Skylake-Client.xml | 7 +- src/cpu_map/x86_Skylake-Server-IBRS.xml | 2 +- src/cpu_map/x86_Skylake-Server.xml | 2 +- src/cpu_map/x86_Westmere-IBRS.xml | 2 +- src/cpu_map/x86_Westmere.xml | 4 +- src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 91 +- src/qemu/qemu_capspriv.h | 8 + tests/cputest.c | 96 ++ tests/cputestdata/cpu-reformat.py | 2 +- tests/cputestdata/x86_64-cpuid-A10-5800K.sig | 4 + tests/cputestdata/x86_64-cpuid-Atom-D510.sig | 4 + tests/cputestdata/x86_64-cpuid-Atom-N450.sig | 4 + .../cputestdata/x86_64-cpuid-Core-i5-2500.sig | 4 + .../x86_64-cpuid-Core-i5-2540M.sig | 4 + .../x86_64-cpuid-Core-i5-4670T.sig | 4 + .../x86_64-cpuid-Core-i5-650-json.xml | 9 +- .../cputestdata/x86_64-cpuid-Core-i5-650.sig | 4 + .../cputestdata/x86_64-cpuid-Core-i5-6600.sig | 4 + .../x86_64-cpuid-Core-i7-2600-xsaveopt.sig | 4 + .../cputestdata/x86_64-cpuid-Core-i7-2600.sig | 4 + .../x86_64-cpuid-Core-i7-3520M.sig | 4 + .../x86_64-cpuid-Core-i7-3740QM.sig | 4 + .../cputestdata/x86_64-cpuid-Core-i7-3770.sig | 4 + .../x86_64-cpuid-Core-i7-4510U.sig | 4 + .../x86_64-cpuid-Core-i7-4600U.sig | 4 + .../x86_64-cpuid-Core-i7-5600U-arat.sig | 4 + .../x86_64-cpuid-Core-i7-5600U-ibrs.sig | 4 + .../x86_64-cpuid-Core-i7-5600U.sig | 4 + .../x86_64-cpuid-Core-i7-7600U-disabled.xml | 6 + .../x86_64-cpuid-Core-i7-7600U-enabled.xml | 8 + .../x86_64-cpuid-Core-i7-7600U-guest.xml | 28 + .../x86_64-cpuid-Core-i7-7600U-host.xml | 29 + .../x86_64-cpuid-Core-i7-7600U-json.xml | 13 + .../x86_64-cpuid-Core-i7-7600U.json | 755 +++++++++++ .../x86_64-cpuid-Core-i7-7600U.sig | 4 + .../x86_64-cpuid-Core-i7-7600U.xml | 47 + .../cputestdata/x86_64-cpuid-Core-i7-7700.sig | 4 + .../cputestdata/x86_64-cpuid-Core2-E6850.sig | 4 + .../cputestdata/x86_64-cpuid-Core2-Q9500.sig | 4 + .../x86_64-cpuid-EPYC-7601-32-Core-ibpb.sig | 4 + .../x86_64-cpuid-EPYC-7601-32-Core.sig | 4 + tests/cputestdata/x86_64-cpuid-FX-8150.sig | 4 + .../cputestdata/x86_64-cpuid-Opteron-1352.sig | 4 + .../cputestdata/x86_64-cpuid-Opteron-2350.sig | 4 + .../cputestdata/x86_64-cpuid-Opteron-6234.sig | 4 + .../cputestdata/x86_64-cpuid-Opteron-6282.sig | 4 + .../x86_64-cpuid-Pentium-P6100-guest.xml | 10 +- .../x86_64-cpuid-Pentium-P6100.sig | 4 + tests/cputestdata/x86_64-cpuid-Phenom-B95.sig | 4 + .../x86_64-cpuid-Ryzen-7-1800X-Eight-Core.sig | 4 + tests/cputestdata/x86_64-cpuid-Xeon-5110.sig | 4 + .../x86_64-cpuid-Xeon-E3-1245-v5.sig | 4 + .../x86_64-cpuid-Xeon-E5-2609-v3.sig | 4 + .../x86_64-cpuid-Xeon-E5-2623-v4-guest.xml | 11 +- .../x86_64-cpuid-Xeon-E5-2623-v4-json.xml | 11 +- .../x86_64-cpuid-Xeon-E5-2623-v4.sig | 4 + .../x86_64-cpuid-Xeon-E5-2630-v3.sig | 4 + .../x86_64-cpuid-Xeon-E5-2630-v4-disabled.xml | 7 + .../x86_64-cpuid-Xeon-E5-2630-v4-enabled.xml | 8 + .../x86_64-cpuid-Xeon-E5-2630-v4-guest.xml | 34 + .../x86_64-cpuid-Xeon-E5-2630-v4-host.xml | 35 + .../x86_64-cpuid-Xeon-E5-2630-v4-json.xml | 14 + .../x86_64-cpuid-Xeon-E5-2630-v4.json | 596 +++++++++ .../x86_64-cpuid-Xeon-E5-2630-v4.sig | 4 + .../x86_64-cpuid-Xeon-E5-2630-v4.xml | 43 + .../x86_64-cpuid-Xeon-E5-2650-disabled.xml | 5 + .../x86_64-cpuid-Xeon-E5-2650-enabled.xml | 8 + .../x86_64-cpuid-Xeon-E5-2650-guest.xml | 29 + .../x86_64-cpuid-Xeon-E5-2650-host.xml | 30 + .../x86_64-cpuid-Xeon-E5-2650-json.xml | 14 + .../x86_64-cpuid-Xeon-E5-2650-v3.sig | 4 + .../x86_64-cpuid-Xeon-E5-2650-v4-guest.xml | 11 +- .../x86_64-cpuid-Xeon-E5-2650-v4-json.xml | 11 +- .../x86_64-cpuid-Xeon-E5-2650-v4.sig | 4 + .../x86_64-cpuid-Xeon-E5-2650.json | 931 ++++++++++++++ .../cputestdata/x86_64-cpuid-Xeon-E5-2650.sig | 4 + .../cputestdata/x86_64-cpuid-Xeon-E5-2650.xml | 34 + .../x86_64-cpuid-Xeon-E7-4820-guest.xml | 8 +- .../x86_64-cpuid-Xeon-E7-4820-json.xml | 8 +- .../cputestdata/x86_64-cpuid-Xeon-E7-4820.sig | 4 + .../x86_64-cpuid-Xeon-E7-4830-json.xml | 9 +- .../cputestdata/x86_64-cpuid-Xeon-E7-4830.sig | 4 + .../x86_64-cpuid-Xeon-E7-8890-v3.sig | 4 + .../x86_64-cpuid-Xeon-E7540-disabled.xml | 5 + .../x86_64-cpuid-Xeon-E7540-enabled.xml | 7 + .../x86_64-cpuid-Xeon-E7540-guest.xml | 25 + .../x86_64-cpuid-Xeon-E7540-host.xml | 26 + .../x86_64-cpuid-Xeon-E7540-json.xml | 14 + .../cputestdata/x86_64-cpuid-Xeon-E7540.json | 1117 +++++++++++++++++ tests/cputestdata/x86_64-cpuid-Xeon-E7540.sig | 4 + tests/cputestdata/x86_64-cpuid-Xeon-E7540.xml | 30 + .../x86_64-cpuid-Xeon-Gold-5115.sig | 4 + .../x86_64-cpuid-Xeon-Gold-6148.sig | 4 + tests/cputestdata/x86_64-cpuid-Xeon-W3520.sig | 4 + tests/cputestdata/x86_64-cpuid-Xeon-X5460.sig | 4 + 124 files changed, 4634 insertions(+), 206 deletions(-) create mode 100644 tests/cputestdata/x86_64-cpuid-A10-5800K.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Atom-D510.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Atom-N450.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i5-2500.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i5-2540M.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i5-4670T.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i5-650.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i5-6600.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-3520M.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-3740QM.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-3770.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-4510U.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-4600U.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-5600U-arat.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-5600U-ibrs.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-5600U.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7600U-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7600U-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7600U-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7600U-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7600U-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7600U.json create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7600U.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7600U.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7700.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core2-E6850.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Core2-Q9500.sig create mode 100644 tests/cputestdata/x86_64-cpuid-EPYC-7601-32-Core-ibpb.sig create mode 100644 tests/cputestdata/x86_64-cpuid-EPYC-7601-32-Core.sig create mode 100644 tests/cputestdata/x86_64-cpuid-FX-8150.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Opteron-1352.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Opteron-2350.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Opteron-6234.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Opteron-6282.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Pentium-P6100.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Phenom-B95.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Ryzen-7-1800X-Eight-Core.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-5110.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E3-1245-v5.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2609-v3.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2623-v4.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v3.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v4-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v4-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v4-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v4-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v4-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v4.json create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v4.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-v4.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v3.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v4.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650.json create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4820.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-8890-v3.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7540-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7540-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7540-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7540-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7540-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7540.json create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7540.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7540.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-Gold-5115.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-Gold-6148.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-W3520.sig create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-X5460.sig -- 2.21.0

2 54

[libvirt] [PATCH v2 0/6] Alter domain_conf to make use of autofree
by John Ferlan 01 Mar '19

01 Mar '19

v1: https://www.redhat.com/archives/libvir-list/2019-February/msg01160.html Changes since v1: * Push patch 1 * Split patch 2 to follow code review guidance: * (Patch1) Pull out virDomainEmulatorPinDefParseXML changes to use VIR_STEAL_PTR * (Patch2) Use VIR_AUTOPTR(virBitmap) * (Patch3) Handle a couple cases where goto's no longer necessary * Drop Patch 3 * Split Patch 4 to follow code review guidance: * (Patch4) Remove unused variables * (Patch5) Just use VIR_AUTOFREE * (Patch6) Handle the removal of goto logic that's no longer necessary John Ferlan (6): conf: Rework virDomainEmulatorPinDefParseXML conf: Use VIR_AUTOPTR(virBitmap) in domain_conf conf: Clean up some unnecessary goto paths conf: Remove a few unused variables in domain_conf conf: Use VIR_AUTOFREE in domain_conf conf: Clean up some unnecessary goto paths src/conf/domain_conf.c | 1937 ++++++++++++++-------------------------- 1 file changed, 676 insertions(+), 1261 deletions(-) -- 2.20.1

2 16

[libvirt] [jenkins-ci PATCH v5 0/5] Add support for cross compiling libvirt via Debian
by Daniel P. Berrangé 01 Mar '19

01 Mar '19

Changed in v5: - Remove redundant formatter class - Update commit message - Update readme - Move misplaced patch chunk - Dont set "dest" in arg when not needed - Use metavar for subparser Changed in v4: - Pull in change to use argparse sub-parsers - Refactor way architecture specific package rules are stored to be in the main package mappings data Changed in v3: - Remove sheepdog more generally - Use .format() style printf - Split config to cross-build.yml - Make glusterfs name per-distro customized - Misc code style changes - Rename fields in cross-build.yml - Don't use crossbuild-essential packages Changed in v2: - Fix multiple package name mistakes - Modify lcitool to generate cross-arch docker files - Add --no-install-recommended flag to apt-get - Add DEBIAN_FRONTEND=noninteractive env to apt-get - Improve error reporting in lcitool - Add make rule for generating dockerfiles locally Daniel P. Berrangé (5): lcitool: use subparsers for commands lcitool: avoid repetition when expanding package mappings lcitool: avoid intermediate list of packages mappings: extend mapping to allow per-arch entries lcitool: support generating cross compiler dockerfiles guests/README.markdown | 18 +- guests/host_vars/libvirt-debian-9/main.yml | 44 ++++ guests/host_vars/libvirt-debian-sid/main.yml | 45 ++++ guests/lcitool | 230 +++++++++++++------ guests/playbooks/update/tasks/packages.yml | 32 +++ guests/vars/mappings.yml | 101 +++++++- 6 files changed, 381 insertions(+), 89 deletions(-) -- 2.20.1

2 16