- Devel - libvirt List Archives

[libvirt] [PATCH v11 0/5] Add native TLS encrypted chardev TCP support
by John Ferlan 26 Oct '16

26 Oct '16

v10: http://www.redhat.com/archives/libvir-list/2016-October/msg00866.html Changes since v10... This is essentially the adding the secret to/for the TLS chardev TCP. Lots of messy stuff. Patches 1-3 are new... In particular, I kept looking at the RNG removal code and kept thinking, something just doesn't look right when compared to the RemoveVirtioDisk code. If I'm incorrect with order of removal it's an easy enough change. Kept trying to think what depends on what and for the RNG it would seem a need a to unplug the backend before removing the front end object would be more logical. Patches 4-5 are the old patch 3-4. They (hopefully) encompass the previous review plus other things since discovered. John Ferlan (5): qemu: Move TLS object remove from DetachChr to RemoveChr qemu: Swap order of RNG hot unplug removal qemu: Need to remove TLS object in RemoveRNGDevice qemu: Add a secret object to/for a char source dev qemu: Add secret object hotplug for TCP chardev TLS src/qemu/qemu_command.c | 30 +++- src/qemu/qemu_command.h | 1 + src/qemu/qemu_domain.c | 173 +++++++++++++++++- src/qemu/qemu_domain.h | 17 +- src/qemu/qemu_driver.c | 6 +- src/qemu/qemu_hotplug.c | 195 +++++++++++++++++---- src/qemu/qemu_hotplug.h | 9 +- src/qemu/qemu_process.c | 9 +- tests/qemuhotplugtest.c | 2 +- ...xml2argv-serial-tcp-tlsx509-secret-chardev.args | 38 ++++ ...uxml2argv-serial-tcp-tlsx509-secret-chardev.xml | 50 ++++++ tests/qemuxml2argvtest.c | 17 ++ 12 files changed, 495 insertions(+), 52 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-secret-chardev.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-secret-chardev.xml -- 2.7.4

2 16

[libvirt] [PATCH v5 00/15] Use more PCIe less legacy PCI
by Laine Stump 26 Oct '16

26 Oct '16

These are just the rebased versions of the patches from v4 that I haven't yet pushed, to make review easier. Patch 1 and 2 (and several others) are already ACKed, but included for completeness. Laine Stump (15): qemu: new functions qemuDomainMachineHasPCI[e]Root() qemu: new functions to calculate/set device pciConnectFlags qemu: set/use info->pciConnectFlags when validating/assigning PCI addresses qemu: set/use proper pciConnectFlags during hotplug qemu: set pciConnectFlags to 0 instead of PCI|HOTPLUGGABLE if device isn't PCI qemu: assign virtio devices to PCIe slot when appropriate qemu: assign e1000e network devices to PCIe slots when appropriate qemu: assign nec-xhci (USB3) controller to a PCIe address when appropriate qemu: only force an available legacy-PCI slot on domains with pci-root qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed [RFC] qemu: if pci-bridge is in PCIe config w/o dmi-to-pci-bridge, add it qemu: don't force-add a dmi-to-pci-bridge just on principle qemu: add a USB3 controller to Q35 domains by default qemu: try to put ich9 sound device at 00:1B.0 qemu: initially reserve one open pcie-root-port for hotplug src/conf/device_conf.h | 5 + src/conf/domain_addr.c | 112 ++- src/conf/domain_addr.h | 3 +- src/qemu/qemu_domain.c | 52 +- src/qemu/qemu_domain.h | 2 + src/qemu/qemu_domain_address.c | 805 +++++++++++++++++---- src/qemu/qemu_domain_address.h | 4 + src/qemu/qemu_hotplug.c | 20 +- tests/qemuxml2argvdata/qemuxml2argv-autoindex.args | 10 +- .../qemuxml2argv-bios-nvram-secure.args | 1 + .../qemuxml2argv-machine-smm-opt.args | 1 + tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args | 3 +- .../qemuxml2argv-q35-default-devices-only.args | 23 + .../qemuxml2argv-q35-default-devices-only.xml | 18 + .../qemuxml2argv-q35-pcie-autoadd.args | 57 ++ .../qemuxml2argv-q35-pcie-autoadd.xml | 51 ++ tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args | 58 ++ tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml | 67 ++ .../qemuxml2argv-q35-pm-disable-fallback.args | 1 + .../qemuxml2argv-q35-pm-disable.args | 1 + .../qemuxml2argv-q35-virt-manager-basic.args | 56 ++ .../qemuxml2argv-q35-virt-manager-basic.xml | 76 ++ .../qemuxml2argv-q35-virtio-pci.args | 58 ++ .../qemuxml2argv-q35-virtio-pci.xml | 1 + tests/qemuxml2argvtest.c | 164 ++++- .../qemuxml2xmlout-autoindex.xml | 10 +- .../qemuxml2xmlout-pcie-root.xml | 4 - .../qemuxml2xmlout-q35-default-devices-only.xml | 45 ++ .../qemuxml2xmlout-q35-pcie-autoadd.xml | 148 ++++ .../qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml | 152 ++++ .../qemuxml2xmlout-q35-virt-manager-basic.xml | 121 ++++ .../qemuxml2xmlout-q35-virtio-pci.xml | 152 ++++ tests/qemuxml2xmltest.c | 136 +++- 33 files changed, 2189 insertions(+), 228 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie-autoadd.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie-autoadd.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virt-manager-basic.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virt-manager-basic.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.args create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-default-devices-only.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie-autoadd.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-virt-manager-basic.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-virtio-pci.xml -- 2.7.4

2 18

[libvirt] [PATCH] qemu: Fix depedency order in qemuRemoveDiskDevice
by John Ferlan 26 Oct '16

26 Oct '16

Need to remove the drive first, then the secobj and/or encobj if they exist. This is because the drive has a dependency on secobj (or the secret for the networked storage server) and/or the encobj (or the secret for the LUKS encrypted volume). Deleting either object first leaves an drive without it's respective objects. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- src/qemu/qemu_hotplug.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 7a21dc6..30565d5 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -3176,6 +3176,9 @@ qemuDomainRemoveDiskDevice(virQEMUDriverPtr driver, qemuDomainObjEnterMonitor(driver, vm); + qemuMonitorDriveDel(priv->mon, drivestr); + VIR_FREE(drivestr); + /* If it fails, then so be it - it was a best shot */ if (objAlias) ignore_value(qemuMonitorDelObject(priv->mon, objAlias)); @@ -3186,8 +3189,6 @@ qemuDomainRemoveDiskDevice(virQEMUDriverPtr driver, ignore_value(qemuMonitorDelObject(priv->mon, encAlias)); VIR_FREE(encAlias); - qemuMonitorDriveDel(priv->mon, drivestr); - VIR_FREE(drivestr); if (qemuDomainObjExitMonitor(driver, vm) < 0) return -1; -- 2.7.4

2 1

[libvirt] [PATCH v2 00/12] Add length (duration) params for iotune throttling
by John Ferlan 25 Oct '16

25 Oct '16

v1: http://www.redhat.com/archives/libvir-list/2016-September/msg01090.html Differences since v1: Patches 1-5 are new... Patch 1 is essentially the former patch 8.5 added after initial review based on a review comment. Erik Skultety and I went back and forth on this one a few times and this is the result Patch 2 is a result of being frustrated by a generic error message when I know we could return whatever qemu gives us Patch 3 is simple code motion - the conf_disk is closer to usage now Patch 4 & 5 create and use the same algorithm to set the default values that weren't provided. Patches 6-7 have already been ACK'd... I've been waiting to push because they will interfere with libvirt-perl builds and since the 2.3.0 hasn't been published yet, I'm still holding onto them. Patch 8 is the former patch 8, but reworked mostly in qemu_driver.c, but also a change in qemu_monitor_json.c to use "P:" instead of "U:" for then length values. For _length a 0 is an invalid value, so we'll use it to mean "nothing changed" Patch 9 is the former patch 11 and is mostly intact, with major difference being the removal of the CHECK_IOTUNE_MAX_LENGTH macro (it was causing domain disappearance) Patch 10 is the former patch 12 and is unchanged. It also has been ACKd Patch 11-12 are new - it's the virsh code. John Ferlan (12): qemu: Create a macro to handle setting bytes/iops iotune values qemu: Return real error message for block_set_io_throttle qemu: Move setting of conf_disk in qemuDomainSetBlockIoTune qemu: Introduce qemuDomainSetBlockIoTuneSetDefaults qemu: Use qemuDomainsetBlockIoTuneSetDefaults for config include: Add new definitions for duration for bps/iops throttling caps: Add new capability for the bps/iops throttling length qemu: Add length for bps/iops throttling parameters to driver conf: Add support for blkiotune "_length" options qemu: Add the length options to the iotune command line virsh: Create a macro to add IOTUNE values virsh: Add _length parameters to virsh output docs/formatdomain.html.in | 40 ++- docs/schemas/domaincommon.rng | 38 +++ include/libvirt/libvirt-domain.h | 102 ++++++ src/conf/domain_conf.c | 24 +- src/conf/domain_conf.h | 6 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 21 ++ src/qemu/qemu_driver.c | 341 +++++++++++---------- src/qemu/qemu_monitor.c | 7 +- src/qemu/qemu_monitor.h | 3 +- src/qemu/qemu_monitor_json.c | 39 ++- src/qemu/qemu_monitor_json.h | 3 +- .../caps_2.6.0-gicv2.aarch64.xml | 1 + .../caps_2.6.0-gicv3.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 1 + tests/qemumonitorjsontest.c | 17 +- .../qemuxml2argv-blkdeviotune-max-length.args | 34 ++ .../qemuxml2argv-blkdeviotune-max-length.xml | 65 ++++ tests/qemuxml2argvtest.c | 4 + .../qemuxml2xmlout-blkdeviotune-max-length.xml | 1 + tests/qemuxml2xmltest.c | 1 + tools/virsh-domain.c | 196 +++++------- tools/virsh.pod | 21 ++ 26 files changed, 673 insertions(+), 298 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-blkdeviotune-max-length.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-blkdeviotune-max-length.xml create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-blkdeviotune-max-length.xml -- 2.7.4

2 29

Re: [libvirt] question about rdma migration
by Michael R. Hines 25 Oct '16

25 Oct '16

Hi Roy, On 02/09/2016 03:57 AM, Roy Shterman wrote: > Hi, > > I tried to understand the rdma-migration in qemu code and i have two > questions about it: > > 1. I'm working with qemu-kvm using libvirt and i'm getting > > MEMLOCK max locked-in-memory address space 65536 65536 bytes > > in qemu process so I don't understand how can you use rdma-pin-all > with such low MEMLOCK. > > I found a solution in libvirt to lock all vm memory in advance and to > enlarge MEMLOCK. > It uses memoryBacking locking and memory tuning hard_limit of vm > memory but I couldn't find a usage of this in rdma-migration code. > You're absolutey right, the RDMA migration code itself doesn't set this lock limit explicitly because there are system-wide restrictions in both appArmour, /etc/security, as well as SELINUX that restrict applications from arbitrarily setting their maximum memory lock limits. The other problem is CGROUPS: If someone sets a cgroup control for maximum memory and forgets about that mlock() limits, then there will be a conflict. So, libvirt must have a policy to deal with all of these possibilities, not just handle a special case for RDMA migration. The only way "simple" way (without patching the problems above) to apply a higher lock limit to QEMU is to set the ulimit for libvirt (or for QEMU if starting QEMU manually) in your environment or the command line with $ ulimit # before attempting the migration, then the RDMA subsystem will be able to lock the memory successfully. The other option is to use /etc/security/limits.conf and set the option for a specific libvirt process user and make sure your libvirt/qemu are not running as root. QEMU itself also has a "mlock" option built into the command line, but it also suffers from the same problem --- you have to find a way (currently) to increase the limit before using the option. > 2. Do you have any comparison of IOPS and bandwidth between TCP > migration and rdma migration? > Yes, lots of comparisons. http://wiki.qemu.org/Features/RDMALiveMigration http://www.canturkisci.com/ETC/papers/IBMJRD2011/preprint.pdf > Regards, > Roy > >

5 15

[libvirt] [PATCH] qemu_driver: unlink new domain cfg file when rollbak
by Chen Hanxiao 25 Oct '16

25 Oct '16

From: Chen Hanxiao <chenhanxiao(a)gmail.com> If we failed to unlink old dom cfg file, we goto rollback. But inside rollback, we fogot to unlink the new dom cfg file. This patch fixes this issue. Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- src/qemu/qemu_driver.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index e6f845d..3f4a2fb 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -19869,6 +19869,7 @@ qemuDomainRenameCallback(virDomainObjPtr vm, char *new_dom_name = NULL; char *old_dom_name = NULL; char *old_dom_cfg_file = NULL; + char *new_dom_cfg_file = NULL; virCheckFlags(0, ret); @@ -19882,6 +19883,11 @@ qemuDomainRenameCallback(virDomainObjPtr vm, goto cleanup; } + if (!(new_dom_cfg_file = virDomainConfigFile(cfg->configDir, + new_dom_name))) { + goto cleanup; + } + event_old = virDomainEventLifecycleNewFromObj(vm, VIR_DOMAIN_EVENT_UNDEFINED, VIR_DOMAIN_EVENT_UNDEFINED_RENAMED); @@ -19909,6 +19915,7 @@ qemuDomainRenameCallback(virDomainObjPtr vm, cleanup: VIR_FREE(old_dom_cfg_file); + VIR_FREE(new_dom_cfg_file); VIR_FREE(old_dom_name); VIR_FREE(new_dom_name); qemuDomainEventQueue(driver, event_old); @@ -19922,6 +19929,10 @@ qemuDomainRenameCallback(virDomainObjPtr vm, vm->def->name = old_dom_name; old_dom_name = NULL; } + + if (virFileExists(new_dom_cfg_file)) + unlink(new_dom_cfg_file); + goto cleanup; } -- 1.8.3.1

1 2

[libvirt] [PATCH python 1/1] fix crash in libvirt_virDomainPin*
by Konstantin Neumoin 25 Oct '16

25 Oct '16

If we pass large(more than cpunum) cpu mask to any libvirt_virDomainPin* methods, it could leads to crash. So we have to check tuple size and ignore extra tuple members. Signed-off-by: Konstantin Neumoin <kneumoin(a)virtuozzo.com> --- libvirt-override.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libvirt-override.c b/libvirt-override.c index fa3e2ca..83b760b 100644 --- a/libvirt-override.c +++ b/libvirt-override.c @@ -1327,7 +1327,7 @@ libvirt_virDomainPinVcpu(PyObject *self ATTRIBUTE_UNUSED, if (VIR_ALLOC_N(cpumap, cpumaplen) < 0) return PyErr_NoMemory(); - for (i = 0; i < tuple_size; i++) { + for (i = 0; i < MIN(cpunum, tuple_size); i++) { PyObject *flag = PyTuple_GetItem(pycpumap, i); bool b; @@ -1392,7 +1392,7 @@ libvirt_virDomainPinVcpuFlags(PyObject *self ATTRIBUTE_UNUSED, if (VIR_ALLOC_N(cpumap, cpumaplen) < 0) return PyErr_NoMemory(); - for (i = 0; i < tuple_size; i++) { + for (i = 0; i < MIN(cpunum, tuple_size); i++) { PyObject *flag = PyTuple_GetItem(pycpumap, i); bool b; @@ -1532,7 +1532,7 @@ libvirt_virDomainPinEmulator(PyObject *self ATTRIBUTE_UNUSED, if (VIR_ALLOC_N(cpumap, cpumaplen) < 0) return PyErr_NoMemory(); - for (i = 0; i < tuple_size; i++) { + for (i = 0; i < MIN(cpunum, tuple_size); i++) { PyObject *flag = PyTuple_GetItem(pycpumap, i); bool b; @@ -1738,7 +1738,7 @@ libvirt_virDomainPinIOThread(PyObject *self ATTRIBUTE_UNUSED, if (VIR_ALLOC_N(cpumap, cpumaplen) < 0) return PyErr_NoMemory(); - for (i = 0; i < tuple_size; i++) { + for (i = 0; i < MIN(cpunum, tuple_size); i++) { PyObject *flag = PyTuple_GetItem(pycpumap, i); bool b; -- 2.5.5

2 1

[libvirt] [PATCH v4 00/25] Use more PCIe less legacy PCI
by Laine Stump 25 Oct '16

25 Oct '16

The latest version of patches to auto-assign appropriate devices in PCIe-capable domains to PCIe slots rather than legacy PCI, and to also auto-add pcie-root-ports as necessary to make this easier. I *think* I've dealt with all of Andrea's great critiques of V3, either in my email responses or in these revised patches. Aside from fixing typos and formatting problems, I also moved several "little cosmetic fixes" out of the bigger functionality-changing patches, and also split out the most confusing part of patch 20 (previously patch 15 - the one that auto-adds pcie-root-port and dmi-to-pci-bridge controllers) into its own patch (doubly useful since the value of that part of the patch is dubious - it is now the [RFC] patch 21) As many of the simple costmetic patches as possible were pushed up to the front of the series (if they weren't already there). If those are ACKed on this round but others aren't, I'll push them immediately so I don't need to resubmit the whole series again. Some of these patches were ACKed last time, but I either had to change them further due to changes in other patches, or I couldn't push them because they have prerequisites that weren't ACKed. I've marked those in the subject line (I've also marked entirely new patches in the subject line). Laine Stump (25): qemu: new functions qemuDomainMachineHasPCI[e]Root() qemu: replace a lot of "def->controllers[i]" with equivalent "cont" qemu: replace "def->nets[i]" with "net" and "def->sounds[i]" with "sound" conf: add typedef for anonymous enum used for memballoon device model qemu: remove superfluous setting of addrs->nbuses qemu: make error message in qemuDomainPCIAddressSetCreate more clear. qemu: change first arg of qemuDomainAttachChrDeviceAssignAddr() conf: new function virDomainPCIAddressReserveNextAddr() qemu: use virDomainPCIAddressReserveNextAddr in qemuDomainAssignDevicePCISlots conf: make virDomainPCIAddressGetNextSlot() a local static function qemu: replace calls to virDomainPCIAddressReserveNext*() with static function qemu: new functions to calculate/set device pciConnectFlags qemu: set/use info->pciConnectFlags when validating/assigning PCI addresses qemu: set/use proper pciConnectFlags during hotplug qemu: set pciConnectFlags to 0 instead of PCI|HOTPLUGGABLE if device isn't PCI qemu: assign virtio devices to PCIe slot when appropriate qemu: assign e1000e network devices to PCIe slots when appropriate qemu: assign nec-xhci (USB3) controller to a PCIe address when appropriate qemu: only force an available legacy-PCI slot on domains with pci-root qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed [RFC] qemu: if pci-bridge is in PCIe config w/o dmi-to-pci-bridge, add it qemu: don't force-add a dmi-to-pci-bridge just on principle qemu: add a USB3 controller to Q35 domains by default qemu: try to put ich9 sound device at 00:1B.0 qemu: initially reserve one open pcie-root-port for hotplug src/conf/device_conf.h | 5 + src/conf/domain_addr.c | 163 ++- src/conf/domain_addr.h | 11 +- src/conf/domain_conf.h | 4 +- src/libvirt_private.syms | 2 +- src/qemu/qemu_domain.c | 52 +- src/qemu/qemu_domain.h | 2 + src/qemu/qemu_domain_address.c | 1097 +++++++++++++++----- src/qemu/qemu_domain_address.h | 4 + src/qemu/qemu_hotplug.c | 27 +- tests/qemuxml2argvdata/qemuxml2argv-autoindex.args | 10 +- .../qemuxml2argv-bios-nvram-secure.args | 1 + .../qemuxml2argv-machine-smm-opt.args | 1 + tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args | 3 +- .../qemuxml2argv-q35-default-devices-only.args | 23 + .../qemuxml2argv-q35-default-devices-only.xml | 18 + .../qemuxml2argv-q35-pcie-autoadd.args | 57 + .../qemuxml2argv-q35-pcie-autoadd.xml | 51 + tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args | 58 ++ tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml | 67 ++ .../qemuxml2argv-q35-pm-disable-fallback.args | 1 + .../qemuxml2argv-q35-pm-disable.args | 1 + .../qemuxml2argv-q35-virt-manager-basic.args | 56 + .../qemuxml2argv-q35-virt-manager-basic.xml | 76 ++ .../qemuxml2argv-q35-virtio-pci.args | 58 ++ .../qemuxml2argv-q35-virtio-pci.xml | 1 + tests/qemuxml2argvtest.c | 164 ++- .../qemuxml2xmlout-autoindex.xml | 10 +- .../qemuxml2xmlout-pcie-root.xml | 4 - .../qemuxml2xmlout-q35-default-devices-only.xml | 45 + .../qemuxml2xmlout-q35-pcie-autoadd.xml | 148 +++ .../qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml | 152 +++ .../qemuxml2xmlout-q35-virt-manager-basic.xml | 121 +++ .../qemuxml2xmlout-q35-virtio-pci.xml | 152 +++ tests/qemuxml2xmltest.c | 136 ++- 35 files changed, 2417 insertions(+), 364 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-default-devices-only.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie-autoadd.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie-autoadd.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virt-manager-basic.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virt-manager-basic.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.args create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-default-devices-only.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie-autoadd.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-virt-manager-basic.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-virtio-pci.xml -- 2.7.4

2 40

[libvirt] [RFC] qemu: Use virtio-pci by default for mach-virt guests
by Andrea Bolognani 25 Oct '16

25 Oct '16

virtio-pci is the way forward for aarch64 guests: it's faster and less alien to people coming from other architectures. Now that guest support is finally getting there, we'd like to start using it by default instead of virtio-mmio. Users and applications can already opt-in by explicitly using <address type='pci'/> inside the relevant elements, but that's kinda cumbersome and requires all users and management applications to adapt, which we'd really like to avoid. What we can do instead is use virtio-mmio only if the guest already has at least one virtio-mmio device, and use virtio-pci in all other situations. That means existing virtio-mmio guests will keep using the old addressing scheme, and new guests will automatically be created using virtio-pci instead. Users can still override the default in either direction. --- Sending this as an RFC for the time being because it clearly needs some more polish, but I wanted to get the idea out there sooner rather than later. It needs to be applied on top of Laine's PCI series[1]. [1] https://www.redhat.com/archives/libvir-list/2016-October/msg00699.html src/qemu/qemu_domain_address.c | 128 ++++++++++++++++++++- ...l2argv-aarch64-virt-2.6-virtio-pci-default.args | 14 ++- .../qemuxml2argv-aarch64-virtio-pci-default.args | 14 ++- .../qemuxml2xmlout-aarch64-virtio-pci-default.xml | 24 +++- 4 files changed, 162 insertions(+), 18 deletions(-) diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c index f27d1e3..7f07764 100644 --- a/src/qemu/qemu_domain_address.c +++ b/src/qemu/qemu_domain_address.c @@ -265,6 +265,118 @@ qemuDomainAssignSpaprVIOAddresses(virDomainDefPtr def, } +static bool +qemuDomainAnyDeviceHasAddressOfType(virDomainDefPtr def, + virDomainDeviceAddressType type) +{ + size_t i; + + for (i = 0; i < def->ndisks; i++) { + if (def->disks[i]->info.type == type) + return true; + } + + for (i = 0; i < def->ncontrollers; i++) { + if (def->controllers[i]->info.type == type) + return true; + } + + for (i = 0; i < def->nfss; i++) { + if (def->fss[i]->info.type == type) + return true; + } + + for (i = 0; i < def->nnets; i++) { + if (def->nets[i]->info.type == type) + return true; + } + + for (i = 0; i < def->ninputs; i++) { + if (def->inputs[i]->info.type == type) + return true; + } + + for (i = 0; i < def->nsounds; i++) { + if (def->sounds[i]->info.type == type) + return true; + } + + for (i = 0; i < def->nvideos; i++) { + if (def->videos[i]->info.type == type) + return true; + } + + for (i = 0; i < def->nhostdevs; i++) { + if (def->hostdevs[i]->info->type == type) + return true; + } + + for (i = 0; i < def->nredirdevs; i++) { + if (def->redirdevs[i]->info.type == type) + return true; + } + + for (i = 0; i < def->nsmartcards; i++) { + if (def->smartcards[i]->info.type == type) + return true; + } + + for (i = 0; i < def->nserials; i++) { + if (def->serials[i]->info.type == type) + return true; + } + + for (i = 0; i < def->nparallels; i++) { + if (def->parallels[i]->info.type == type) + return true; + } + + for (i = 0; i < def->nchannels; i++) { + if (def->channels[i]->info.type == type) + return true; + } + + for (i = 0; i < def->nconsoles; i++) { + if (def->consoles[i]->info.type == type) + return true; + } + + for (i = 0; i < def->nhubs; i++) { + if (def->hubs[i]->info.type == type) + return true; + } + + for (i = 0; i < def->nrngs; i++) { + if (def->rngs[i]->info.type == type) + return true; + } + + for (i = 0; i < def->nshmems; i++) { + if (def->shmems[i]->info.type == type) + return true; + } + + for (i = 0; i < def->nmems; i++) { + if (def->mems[i]->info.type == type) + return true; + } + + if (def->memballoon && def->memballoon->info.type == type) + return true; + + if (def->watchdog && def->watchdog->info.type == type) + return true; + + if (def->nvram && def->nvram->info.type == type) + return true; + + if (def->tpm && def->tpm->info.type == type) + return true; + + return false; +} + + static void qemuDomainPrimeVirtioDeviceAddresses(virDomainDefPtr def, virDomainDeviceAddressType type) @@ -390,6 +502,8 @@ static void qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr def, virQEMUCapsPtr qemuCaps) { + bool usesMMIO; + if (def->os.arch != VIR_ARCH_ARMV7L && def->os.arch != VIR_ARCH_AARCH64) return; @@ -398,9 +512,17 @@ qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr def, qemuDomainMachineIsVirt(def))) return; - if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MMIO)) { - qemuDomainPrimeVirtioDeviceAddresses( - def, VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO); + /* We use virtio-mmio by default on mach-virt guests only if they already + * have at least one virtio-mmio device: in all other cases, we prefer + * virtio-pci */ + usesMMIO = qemuDomainAnyDeviceHasAddressOfType(def, + VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO); + if (qemuDomainMachineHasPCIeRoot(def) && !usesMMIO) { + qemuDomainPrimeVirtioDeviceAddresses(def, + VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI); + } else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MMIO)) { + qemuDomainPrimeVirtioDeviceAddresses(def, + VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO); } } diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-2.6-virtio-pci-default.args b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-2.6-virtio-pci-default.args index 75db1a4..df03c6e 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-2.6-virtio-pci-default.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-2.6-virtio-pci-default.args @@ -21,14 +21,18 @@ QEMU_AUDIO_DRV=none \ -initrd /aarch64.initrd \ -append 'earlyprintk console=ttyAMA0,115200n8 rw root=/dev/vda rootwait' \ -dtb /aarch64.dtb \ --device virtio-serial-device,id=virtio-serial0 \ +-device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 \ +-device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 \ +-device ioh3420,port=0x10,chassis=3,id=pci.3,bus=pcie.0,addr=0x2 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x2 \ -drive file=/aarch64.raw,format=raw,if=none,id=drive-virtio-disk0 \ --device virtio-blk-device,drive=drive-virtio-disk0,id=virtio-disk0 \ --device virtio-net-device,vlan=0,id=net0,mac=52:54:00:09:a4:37 \ +-device virtio-blk-pci,bus=pci.2,addr=0x3,drive=drive-virtio-disk0,\ +id=virtio-disk0 \ +-device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:09:a4:37,bus=pci.2,addr=0x1 \ -net user,vlan=0,name=hostnet0 \ -serial pty \ -chardev pty,id=charconsole1 \ -device virtconsole,chardev=charconsole1,id=console1 \ --device virtio-balloon-device,id=balloon0 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x4 \ -object rng-random,id=objrng0,filename=/dev/random \ --device virtio-rng-device,rng=objrng0,id=rng0 +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.2,addr=0x5 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-default.args b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-default.args index b5b010c..f205d9a 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-default.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-default.args @@ -21,14 +21,18 @@ QEMU_AUDIO_DRV=none \ -initrd /aarch64.initrd \ -append 'earlyprintk console=ttyAMA0,115200n8 rw root=/dev/vda rootwait' \ -dtb /aarch64.dtb \ --device virtio-serial-device,id=virtio-serial0 \ +-device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 \ +-device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 \ +-device ioh3420,port=0x10,chassis=3,id=pci.3,bus=pcie.0,addr=0x2 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x2 \ -drive file=/aarch64.raw,format=raw,if=none,id=drive-virtio-disk0 \ --device virtio-blk-device,drive=drive-virtio-disk0,id=virtio-disk0 \ --device virtio-net-device,vlan=0,id=net0,mac=52:54:00:09:a4:37 \ +-device virtio-blk-pci,bus=pci.2,addr=0x3,drive=drive-virtio-disk0,\ +id=virtio-disk0 \ +-device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:09:a4:37,bus=pci.2,addr=0x1 \ -net user,vlan=0,name=hostnet0 \ -serial pty \ -chardev pty,id=charconsole1 \ -device virtconsole,chardev=charconsole1,id=console1 \ --device virtio-balloon-device,id=balloon0 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x4 \ -object rng-random,id=objrng0,filename=/dev/random \ --device virtio-rng-device,rng=objrng0,id=rng0 +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.2,addr=0x5 diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-default.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-default.xml index 7c3fc19..90659a1 100644 --- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-default.xml +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-default.xml @@ -30,16 +30,30 @@ <disk type='file' device='disk'> <source file='/aarch64.raw'/> <target dev='vda' bus='virtio'/> - <address type='virtio-mmio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/> </disk> <controller type='pci' index='0' model='pcie-root'/> <controller type='virtio-serial' index='0'> - <address type='virtio-mmio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/> + </controller> + <controller type='pci' index='1' model='dmi-to-pci-bridge'> + <model name='i82801b11-bridge'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> + </controller> + <controller type='pci' index='2' model='pci-bridge'> + <model name='pci-bridge'/> + <target chassisNr='2'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </controller> + <controller type='pci' index='3' model='pcie-root-port'> + <model name='ioh3420'/> + <target chassis='3' port='0x10'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </controller> <interface type='user'> <mac address='52:54:00:09:a4:37'/> <model type='virtio'/> - <address type='virtio-mmio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> @@ -51,11 +65,11 @@ <target type='virtio' port='1'/> </console> <memballoon model='virtio'> - <address type='virtio-mmio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/> </memballoon> <rng model='virtio'> <backend model='random'>/dev/random</backend> - <address type='virtio-mmio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x05' function='0x0'/> </rng> </devices> </domain> -- 2.7.4

4 9

[libvirt] how to install and remove Libvirt cleanly
by zhunxun＠gmail.com 25 Oct '16

25 Oct '16

I just want to know how to uninstall Libvirt which installed by source code cleanly.because I found make uninstall can not remove all the installed file.so that I install it later failed. zhunxun(a)gmail.com

1 0

[libvirt] [PATCH 0/4] Add VCPU halted to domain statistics
by Viktor Mihajlovski 25 Oct '16

25 Oct '16

As a result of the discussions on https://www.redhat.com/archives/libvir-list/2016-October/msg00531.html: In order to be able to report the per VCPU halted condition as returned by the QEMU monitor this series extends the VCPU-specific domain statistics with a vcpu.n.halted value. This is done by - extending the monitor to pass back the halted condition for the vcpus - adding a new field to the private domain vcpu object reflecting the halted condition for the vcpu - modifying the driver code to report the new VCPU domain statistics value The halted condition is however not recorded in the internal XML format, since the state can change asynchronously (without notification). Patches 1/4 and 2/4 are taken without modifications from the original posting. In 4/4 I've only updated virsh.pod as I didn't want to touch libvirt-domain.c in this context just for documentation purposes. Viktor Mihajlovski (4): qemu: Add monitor support for CPU halted state qemu: Add domain support for VCPU halted state qemu: add vcpu.n.halted to vcpu domain stats doc: update virsh domstats documentation for vcpu statistics src/qemu/qemu_domain.c | 66 ++++++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_domain.h | 5 ++++ src/qemu/qemu_driver.c | 34 ++++++++++++++++++++--- src/qemu/qemu_monitor.c | 6 +++- src/qemu/qemu_monitor.h | 3 ++ src/qemu/qemu_monitor_json.c | 3 ++ src/qemu/qemu_monitor_text.c | 8 +++++- tests/qemumonitorjsontest.c | 8 +++--- tools/virsh.pod | 7 +++++ 9 files changed, 130 insertions(+), 10 deletions(-) -- 1.9.1

2 8

[libvirt] [jenkins-ci PATCH] jobs: change maintainer email address
by Pavel Hrdina 25 Oct '16

25 Oct '16

Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- Pushed as trivial. jobs/defaults.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jobs/defaults.yaml b/jobs/defaults.yaml index 23d9ae7..b21bff3 100644 --- a/jobs/defaults.yaml +++ b/jobs/defaults.yaml @@ -9,4 +9,4 @@ MAKE='gmake' fi smp: 3 - spam: shajyan(a)redhat.com libvirt-ci(a)redhat.com + spam: ymankad(a)redhat.com libvirt-ci(a)redhat.com -- 2.10.1

1 0

[libvirt] [PATCH] libxl: fix leaking of allocated migration ports
by Jim Fehlig 25 Oct '16

25 Oct '16

Although the migration port is immediately released in the finish phase of migration, it was never set in the domain private object when allocated in the prepare phase. So libxlDomainMigrationFinish() always released a 0-initialized migrationPort, leaking any allocated port. After enough migrations to exhaust the migration port pool, migration would fail with error: internal error: Unable to find an unused port in range 'migration' (49152-49216) Fix it by setting libxlDomainObjPrivate->migrationPort to the port allocated in the prepare phase. While at it, also fix leaking an allocated port if the prepare phase fails. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- src/libxl/libxl_migration.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c index 534abb8..a471d2a 100644 --- a/src/libxl/libxl_migration.c +++ b/src/libxl/libxl_migration.c @@ -594,6 +594,7 @@ libxlDomainMigrationPrepare(virConnectPtr dconn, if (virPortAllocatorAcquire(driver->migrationPorts, &port) < 0) goto error; + priv->migrationPort = port; if (virAsprintf(uri_out, "tcp://%s:%d", hostname, port) < 0) goto error; } else { @@ -628,6 +629,7 @@ libxlDomainMigrationPrepare(virConnectPtr dconn, if (virPortAllocatorAcquire(driver->migrationPorts, &port) < 0) goto error; + priv->migrationPort = port; } else { port = uri->port; } @@ -690,6 +692,8 @@ libxlDomainMigrationPrepare(virConnectPtr dconn, } VIR_FREE(socks); virObjectUnref(args); + virPortAllocatorRelease(driver->migrationPorts, priv->migrationPort); + priv->migrationPort = 0; /* Remove virDomainObj from domain list */ if (vm) { -- 2.9.2

2 2

[libvirt] [RFC PATCH v2] qemu: Use virtio-pci by default for mach-virt guests
by Andrea Bolognani 25 Oct '16

25 Oct '16

virtio-pci is the way forward for aarch64 guests: it's faster and less alien to people coming from other architectures. Now that guest support is finally getting there, we'd like to start using it by default instead of virtio-mmio. Users and applications can already opt-in by explicitly using <address type='pci'/> inside the relevant elements, but that's kind of cumbersome and requires all users and management applications to adapt, which we'd really like to avoid. What we can do instead is use virtio-mmio only if the guest already has at least one virtio-mmio device, and use virtio-pci in all other situations. That means existing virtio-mmio guests will keep using the old addressing scheme, and new guests will automatically be created using virtio-pci instead. Users can still override the default in either direction. --- RFC: still needs polish (documentation, test cases) before it can be considered for merging, plus it builds on top of changes that haven't made it into master yet. Changes from v1: * use virDomainDeviceInfoIterate(), as suggested by Martin and Laine, which results in cleaner and more robust code src/qemu/qemu_domain_address.c | 39 ++++++++++++++++++++-- ...l2argv-aarch64-virt-2.6-virtio-pci-default.args | 14 +++++--- .../qemuxml2argv-aarch64-virtio-pci-default.args | 14 +++++--- .../qemuxml2xmlout-aarch64-virtio-pci-default.xml | 24 ++++++++++--- 4 files changed, 73 insertions(+), 18 deletions(-) diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c index f27d1e3..30b1ddf 100644 --- a/src/qemu/qemu_domain_address.c +++ b/src/qemu/qemu_domain_address.c @@ -386,6 +386,32 @@ qemuDomainAssignS390Addresses(virDomainDefPtr def, } +static int +qemuDomainCountVirtioMMIODevicesCallback(virDomainDefPtr def ATTRIBUTE_UNUSED, + virDomainDeviceDefPtr dev ATTRIBUTE_UNUSED, + virDomainDeviceInfoPtr info, + void *opaque) +{ + if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO) + (*((size_t *) opaque))++; + + return 0; +} + + +static size_t +qemuDomainCountVirtioMMIODevices(virDomainDefPtr def) +{ + size_t count = 0; + + virDomainDeviceInfoIterate(def, + qemuDomainCountVirtioMMIODevicesCallback, + &count); + + return count; +} + + static void qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr def, virQEMUCapsPtr qemuCaps) @@ -398,9 +424,16 @@ qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr def, qemuDomainMachineIsVirt(def))) return; - if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MMIO)) { - qemuDomainPrimeVirtioDeviceAddresses( - def, VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO); + /* We use virtio-mmio by default on mach-virt guests only if they already + * have at least one virtio-mmio device: in all other cases, we prefer + * virtio-pci */ + if (qemuDomainMachineHasPCIeRoot(def) && + qemuDomainCountVirtioMMIODevices(def) == 0) { + qemuDomainPrimeVirtioDeviceAddresses(def, + VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI); + } else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MMIO)) { + qemuDomainPrimeVirtioDeviceAddresses(def, + VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO); } } diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-2.6-virtio-pci-default.args b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-2.6-virtio-pci-default.args index 75db1a4..df03c6e 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-2.6-virtio-pci-default.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-2.6-virtio-pci-default.args @@ -21,14 +21,18 @@ QEMU_AUDIO_DRV=none \ -initrd /aarch64.initrd \ -append 'earlyprintk console=ttyAMA0,115200n8 rw root=/dev/vda rootwait' \ -dtb /aarch64.dtb \ --device virtio-serial-device,id=virtio-serial0 \ +-device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 \ +-device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 \ +-device ioh3420,port=0x10,chassis=3,id=pci.3,bus=pcie.0,addr=0x2 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x2 \ -drive file=/aarch64.raw,format=raw,if=none,id=drive-virtio-disk0 \ --device virtio-blk-device,drive=drive-virtio-disk0,id=virtio-disk0 \ --device virtio-net-device,vlan=0,id=net0,mac=52:54:00:09:a4:37 \ +-device virtio-blk-pci,bus=pci.2,addr=0x3,drive=drive-virtio-disk0,\ +id=virtio-disk0 \ +-device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:09:a4:37,bus=pci.2,addr=0x1 \ -net user,vlan=0,name=hostnet0 \ -serial pty \ -chardev pty,id=charconsole1 \ -device virtconsole,chardev=charconsole1,id=console1 \ --device virtio-balloon-device,id=balloon0 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x4 \ -object rng-random,id=objrng0,filename=/dev/random \ --device virtio-rng-device,rng=objrng0,id=rng0 +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.2,addr=0x5 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-default.args b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-default.args index b5b010c..f205d9a 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-default.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-default.args @@ -21,14 +21,18 @@ QEMU_AUDIO_DRV=none \ -initrd /aarch64.initrd \ -append 'earlyprintk console=ttyAMA0,115200n8 rw root=/dev/vda rootwait' \ -dtb /aarch64.dtb \ --device virtio-serial-device,id=virtio-serial0 \ +-device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 \ +-device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 \ +-device ioh3420,port=0x10,chassis=3,id=pci.3,bus=pcie.0,addr=0x2 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x2 \ -drive file=/aarch64.raw,format=raw,if=none,id=drive-virtio-disk0 \ --device virtio-blk-device,drive=drive-virtio-disk0,id=virtio-disk0 \ --device virtio-net-device,vlan=0,id=net0,mac=52:54:00:09:a4:37 \ +-device virtio-blk-pci,bus=pci.2,addr=0x3,drive=drive-virtio-disk0,\ +id=virtio-disk0 \ +-device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:09:a4:37,bus=pci.2,addr=0x1 \ -net user,vlan=0,name=hostnet0 \ -serial pty \ -chardev pty,id=charconsole1 \ -device virtconsole,chardev=charconsole1,id=console1 \ --device virtio-balloon-device,id=balloon0 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x4 \ -object rng-random,id=objrng0,filename=/dev/random \ --device virtio-rng-device,rng=objrng0,id=rng0 +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.2,addr=0x5 diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-default.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-default.xml index 7c3fc19..90659a1 100644 --- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-default.xml +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-default.xml @@ -30,16 +30,30 @@ <disk type='file' device='disk'> <source file='/aarch64.raw'/> <target dev='vda' bus='virtio'/> - <address type='virtio-mmio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/> </disk> <controller type='pci' index='0' model='pcie-root'/> <controller type='virtio-serial' index='0'> - <address type='virtio-mmio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/> + </controller> + <controller type='pci' index='1' model='dmi-to-pci-bridge'> + <model name='i82801b11-bridge'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> + </controller> + <controller type='pci' index='2' model='pci-bridge'> + <model name='pci-bridge'/> + <target chassisNr='2'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </controller> + <controller type='pci' index='3' model='pcie-root-port'> + <model name='ioh3420'/> + <target chassis='3' port='0x10'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </controller> <interface type='user'> <mac address='52:54:00:09:a4:37'/> <model type='virtio'/> - <address type='virtio-mmio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> @@ -51,11 +65,11 @@ <target type='virtio' port='1'/> </console> <memballoon model='virtio'> - <address type='virtio-mmio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/> </memballoon> <rng model='virtio'> <backend model='random'>/dev/random</backend> - <address type='virtio-mmio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x05' function='0x0'/> </rng> </devices> </domain> -- 2.7.4

2 1

[libvirt] [PATCH 00/11] clean up after "slot sharing" patches
by Laine Stump 24 Oct '16

24 Oct '16

Some of the patches that enabled sharing PCI slots by multiple pcie-root-ports made the idea of reserving an entire slot obsolete. To reduce confusion and misunderstandings, this patch series gets rid of the name "Slot" in all of the functions that reserve and release PCI addresses. None of these patches affect any functional change. This is a lot of patches, but each patch is trivial, I promise - most are simply renaming a single function, or changing one argument to some calls to a function. Laine Stump (11): conf: fix fromConfig argument to virDomainPCIAddressReserveAddr() conf: fix fromConfig argument to virDomainPCIAddressValidate() conf: rename virDomainPCIAddressGetNextSlot() to ...GetNextAddr() conf: eliminate virDomainPCIAddressReserveNextSlot() qemu: replace virDomainPCIAddressReserveAddr with virDomainPCIAddressReserveSlot conf: make virDomainPCIAddressReserveAddr() a static function conf: rename virDomainPCIAddressReserveAddr() to ...Internal() conf: rename virDomainPCIAddressReserveSlot() to ...Addr() qemu: remove qemuDomainPCIAddressReserveNextAddr() qemu: rename qemuDomainPCIAddressReserveNextSlot() to ...Addr() conf: eliminate virDomainPCIAddressReleaseSlot() in favor of ...Addr() src/bhyve/bhyve_device.c | 26 +++++++---- src/conf/domain_addr.c | 60 ++++++------------------ src/conf/domain_addr.h | 15 ------ src/libvirt_private.syms | 4 +- src/qemu/qemu_domain_address.c | 102 +++++++++++++++++++---------------------- 5 files changed, 78 insertions(+), 129 deletions(-) -- 2.7.4

1 11

[libvirt] [PATCH 0/8] aggregate multiple pcie-root-ports onto a single slot
by Laine Stump 24 Oct '16

24 Oct '16

These patches implement a reccomendation from Gerd Hoffman during discussion of Marcel Apfelbaum's proposed "PCIe devices placement guidelines" document on qemu-devel: https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg01381.html The basic idea is to put up to 8 pcie-root-ports on each slot of pcie-root, rather than libvirt's historical practice of assigning only a single device to each slot. This is done by defining a new pciConnectFlag - VIR_PCI_CONNECT_AGGREGATE_SLOT - which is set for any device that can be automatically placed together with other similarly flagged devices on multiple functions of the same slot. In this way we can auto-address up to 224 hotpluggable PCIe devices without needing to figure out how to automatically add upstream/downstream ports. Other types of devices could be given the same treatment, although it would make no sense for anything that you wanted to be hotplugable. In order for this all to work nicely and make sense, the PCI address reservation code has eliminated the "reserveEntireSlot" concept - if the first device assigned to a particular slot doesn't have the AGGREGATE_SLOT flag set, then it will be the only device allowed on that slot even though the address set only shows function 0 as being in use. After all of this change, using the term "Slot" in so many function names no longer makes sense; there is another patchset that I will post shortly that gets rid of all that "old inaccurate" naming. I made it separate because it isn't strictly necessary for the AGGREGATE_SLOT functionality. This series needs to be applied on top of my earlier series that adds support for plugging virtio devices into PCIe slots. Laine Stump (8): conf: use struct instead of int for each slot in virDomainPCIAddressBus conf: eliminate concept of "reserveEntireSlot" conf: eliminate repetitive code in virDomainPCIAddressGetNextSlot() conf: start search for next unused PCI address at same slot as previous find conf: new function virDomainPCIAddressIsMulti() qemu: use virDomainPCIAddressIsMulti() to determine multifunction setting conf: aggregate multiple devices on a slot when assigning PCI addresses conf: aggregate multiple pcie-root-ports onto a single slot src/conf/domain_addr.c | 290 ++++++++++++++------- src/conf/domain_addr.h | 48 +++- src/libvirt_private.syms | 1 + src/qemu/qemu_command.c | 16 +- src/qemu/qemu_domain_address.c | 35 ++- .../qemuxml2argv-pcie-root-port.args | 5 +- .../qemuxml2argv-pcie-switch-upstream-port.args | 5 +- .../qemuxml2argv-q35-default-devices-only.args | 7 +- .../qemuxml2argv-q35-multifunction.args | 43 +++ .../qemuxml2argv-q35-multifunction.xml | 51 ++++ .../qemuxml2argv-q35-pcie-autoadd.args | 30 ++- tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args | 28 +- .../qemuxml2argv-q35-virt-manager-basic.args | 13 +- .../qemuxml2argv-q35-virtio-pci.args | 28 +- tests/qemuxml2argvtest.c | 25 ++ .../qemuxml2xmlout-pcie-root-port.xml | 2 +- .../qemuxml2xmlout-pcie-switch-upstream-port.xml | 4 +- .../qemuxml2xmlout-q35-default-devices-only.xml | 8 +- .../qemuxml2xmlout-q35-multifunction.xml | 120 +++++++++ .../qemuxml2xmlout-q35-pcie-autoadd.xml | 52 ++-- .../qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml | 48 ++-- .../qemuxml2xmlout-q35-virt-manager-basic.xml | 20 +- .../qemuxml2xmlout-q35-virtio-pci.xml | 48 ++-- tests/qemuxml2xmltest.c | 25 ++ 24 files changed, 676 insertions(+), 276 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-multifunction.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-multifunction.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-multifunction.xml -- 2.7.4

1 8

[libvirt] [PATCH] virQEMUCapsReset: also clear out hostCPUModel
by Ján Tomko 24 Oct '16

24 Oct '16

After succesfully reading an outdated caps cache from disk, calling virQEMUCapsReset did not properly clear out the host CPU model. This lead to a memory leak when the host CPU model pointer was overwritten later in virQEMUCapsNewForBinaryInternal. Introduced by commit 68c70118. --- src/qemu/qemu_capabilities.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 9132469..130f1db 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -3430,6 +3430,9 @@ virQEMUCapsReset(virQEMUCapsPtr qemuCaps) VIR_FREE(qemuCaps->gicCapabilities); qemuCaps->ngicCapabilities = 0; + + virCPUDefFree(qemuCaps->hostCPUModel); + qemuCaps->hostCPUModel = NULL; } -- 2.7.3

2 1

[libvirt] [PATCH 0/3] last part of TLS encryption for char devices
by Pavel Hrdina 24 Oct '16

24 Oct '16

Pavel Hrdina (3): qemu_hotplug: remove union for one member domain: Add optional 'tls' attribute for TCP chardev domain: fix migration to older libvirt docs/formatdomain.html.in | 28 +++++++++ docs/schemas/domaincommon.rng | 5 ++ src/conf/domain_conf.c | 67 +++++++++++++++++----- src/conf/domain_conf.h | 6 +- src/qemu/qemu_command.c | 4 +- src/qemu/qemu_domain.c | 67 ++++++++++++++++++++++ src/qemu/qemu_domain.h | 8 +++ src/qemu/qemu_hotplug.c | 16 ++++-- src/qemu/qemu_process.c | 2 + ...uxml2argv-serial-tcp-tlsx509-chardev-notls.args | 30 ++++++++++ ...muxml2argv-serial-tcp-tlsx509-chardev-notls.xml | 50 ++++++++++++++++ tests/qemuxml2argvtest.c | 3 + ...xml2xmlout-serial-tcp-tlsx509-chardev-notls.xml | 1 + tests/qemuxml2xmltest.c | 1 + 14 files changed, 266 insertions(+), 22 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev-notls.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev-notls.xml create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-serial-tcp-tlsx509-chardev-notls.xml -- 2.10.1

2 9

[libvirt] [PATCH] doc: Describe the VCPU states returned by virsh vcpuinfo
by Viktor Mihajlovski 24 Oct '16

24 Oct '16

Added a brief description of the VCPU states. Signed-off-by: Viktor Mihajlovski <mihajlov(a)linux.vnet.ibm.com> --- tools/virsh.pod | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/tools/virsh.pod b/tools/virsh.pod index 9e3a248..6d4fd07 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -2536,6 +2536,55 @@ vCPUs, the running time, the affinity to physical processors. With I<--pretty>, cpu affinities are shown as ranges. +An example output is + + $ virsh vcpuinfo fedora + VCPU: 0 + CPU: 0 + State: running + CPU time: 7,0s + CPU Affinity: yyyy + + VCPU: 1 + CPU: 1 + State: running + CPU time: 0,7s + CPU Affinity: yyyy + +B<STATES> + +The State field displays the current operating state of a virtual CPU + +=over 4 + +=item B<offline> + +The virtual CPU is offline and not usable by the domain. +This state is not supported by all hypervisors. + +=item B<running> + +The virtual CPU is available to the domain and is operating. + +=item B<blocked> + +The virtual CPU is available to the domain but is waiting for a resource. +This state is not supported by all hypervisors, in which case I<running> +may be reported instead. + +=item B<no state> + +The virtual CPU state could not be determined. This could happen if +the hypervisor is newer than virsh. + +=item B<N/A> + +There's no information about the virtual CPU state available. This can +be the case if the domain is not running or the hypervisor does +not report the virtual CPU state. + +=back + =item B<vcpupin> I<domain> [I<vcpu>] [I<cpulist>] [[I<--live>] [I<--config>] | [I<--current>]] -- 1.9.1

2 2

[libvirt] [PATCH] domain_conf: fix memory leak in virDomainDefAddConsoleCompat
by Pavel Hrdina 24 Oct '16

24 Oct '16

Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/conf/domain_conf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 748ffd5..6100c3d 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -3895,7 +3895,7 @@ virDomainDefAddConsoleCompat(virDomainDefPtr def) 0, def->nconsoles, chr) < 0) { - VIR_FREE(chr); + virDomainChrDefFree(chr); return -1; } -- 2.10.1

2 1

[libvirt] Race in log manager causes segfault
by Bjoern Walk 24 Oct '16

24 Oct '16

Hello, I am currently investigating a rare segfault in libvirt. I have attached a backtrace, the coredump is for s390x. I am currently trying to reproduce the segfault on x86 but it did not occur yet (timespan to short). This can be triggered by rapidly performing domain start/stop cycles in a tight loop and will trigger in the order of a couple weeks. I have come to the conclusion that there seems to be a race condition in the log manager client. When the log manager gets freed via virLogManagerFree() it (asynchronously) invokes virNetClientClose() and unrefs the associated client structure in virLogManager. If there are other threads waiting for data on the socket they will be woken up but because they rely on virLogManager holding a ref to the client we get a use-after-free. Can anyone verify this analysis and either provide a fix or at least give me some pointers in the right direction on how to further proceed for debugging? Should I open a bug for this? Best regards, Bjoern

1 0

[libvirt] Plans for next release 2.4.0
by Daniel Veillard 24 Oct '16

24 Oct '16

I will be in vacation this week, but should be able to make the release candidate on Thursday, which means that if I can make a CR2 release on the week-end, we should be able to push 2.4.0 around Nov 1st if everything looks good. There is a few tests who went red in https://ci.centos.org/view/libvirt-project/ maybe something to look at in the meantime, thanks ! Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

1 0

[libvirt] [PATCH 0/4] Complete virDomainChrSourceDefPtr adjustments
by John Ferlan 24 Oct '16

24 Oct '16

Similar to _virDomainChrDef, alter _virDomainSmartcardDef and _virDomainRedirdevDef in order to use a virDomainChrSourceDefPtr. This includes modifying the relevant allocations for the source. Next, modify the virDomainRNGDef allocation to use virDomainChrSourceNew rather than a straight VIR_ALLOC. Finally, add the "missing" iterators for RNG and Redirdev. All this should set up what's necessary in order to handle adding the TLS chardev TCP for all chr, smartcard, rng, and redirdev devices. John Ferlan (4): conf: Use virDomainChrSourceDefPtr for _virDomainSmartcardDef 'passthru' conf: Use virDomainChrSourceDefPtr for _virDomainRedirdevDef 'source.chr' conf: Use virDomainChrSourceDefNew for virDomainRNGDef allocation conf: Add iterators for RNG and Redirdev src/conf/domain_audit.c | 2 +- src/conf/domain_conf.c | 122 ++++++++++++++++++++++++++++++---------- src/conf/domain_conf.h | 22 +++++++- src/libvirt_private.syms | 2 + src/qemu/qemu_command.c | 4 +- src/qemu/qemu_hotplug.c | 2 +- src/security/security_selinux.c | 4 +- 7 files changed, 119 insertions(+), 39 deletions(-) -- 2.7.4

2 8

[libvirt] [PATCH 0/4] Add TLS for TCP chardev redirdev and rng backends
by John Ferlan 24 Oct '16

24 Oct '16

This "would" conflict with other TLS/TCP changes on list depending on order of commit, but it does work against the current top. The conflict would be limited to the new helper qemuDomainGetChardevTLSObjects and changing the 'if (!cfg->chardevTLS)' to the corresponding 'if dev->source.data.tcp.haveTLS != VIR_TRISTATE_BOOL_YES)' once Pavel's changes are in and of course removing the need to fetch 'cfg'. Then if my other changes related to making 'source' a pointer in the _virDomainChrDef is accepted, the 'source.' here would change to 'source->'. Essentially during the review process of adding a secret to access the TLS environment, it was determined that the backends for redirdev and rng weren't adding the TLS object on hotplug, even though the command line processing would add it. NB: Smartcard would be in the same category, but it doesn't support hotplug, so we're off the hook for that. John Ferlan (4): qemu: Introduce qemuDomainGetChardevTLSObjects for hotplug qemu: Clean up error path in qemuDomainAttachRedirdevDevice qemu: Add TLS hotplug for qemuDomainAttachRedirdevDevice qemu: Add TLS hotplug for qemuDomainAttachRNGDevice src/qemu/qemu_hotplug.c | 125 ++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 99 insertions(+), 26 deletions(-) -- 2.7.4

2 8

[libvirt] 转发: Re: How libvirt address qemu command line args
by zhunxun＠gmail.com 23 Oct '16

23 Oct '16

zhunxun(a)gmail.com 发件人： zhunxun(a)gmail.com 发送时间： 2016-10-23 17:42 收件人： berrange 主题： Re: Re: [libvirt] How libvirt address qemu command line args Thanks，However,I have to use this method.Now I wander how get the VM xml contents in Libvirt source code,I try output some message in qemuProcessStart function like this ,but I get nothing,anyone can help me?? thanks! my code is : in qemuStartProcess function char *str=qemuDomainDefFormatXML(driver, vm->def, 0); FILE *op=fopen("/root/libvirt.log","a"); if(op!=NULL){ if(str!=NULL) fprintf(op,"str----cmd : %s\n",str); else fprintf(op,"str is null\n"); fclose(op); }else{ fprintf(op,"open file error!\n"); } zhunxun(a)gmail.com From: Daniel P. Berrange Date: 2016-10-19 15:35 To: Michal Privoznik CC: zhunxun(a)gmail.com; libvir-list Subject: Re: [libvirt] How libvirt address qemu command line args On Wed, Oct 19, 2016 at 10:17:21AM +0800, Michal Privoznik wrote: > On 18.10.2016 14:59, zhunxun(a)gmail.com wrote: > > Now I want to add some args about TPM to domain's XML,so I can start a domain by virt-manager or other virsh command,and then ,I would like to use sVIrt security context to label vTPM and correspondingVM,But I do not know how to get these XML args in libvirt. > > the key problem is that how can i get and recognize these args!!! > > related XML content : > > Usually, grepping the code for cmd name <-> XML element/attribute > translation is sufficient (esp. if you grep tests/) > > > > > <qemu:commandline> > > <qemu:arg value='-enable-kvm'/> > > Firstly, this is obsolete in favour of "-machine accel=kvm". In any > case, <domain type='kvm'/> will do the trick (libvirt will use whatever > is supported by qemu binary in your system). > > > <qemu:arg value='-drive'/> > > <qemu:arg value='file=/root/nvram_2.0-jin.qcow2,if=none,id=nvram0-0-0,format=qcow2'/> > > Okay, this is not supported by libvirt yet. We don't really have a way > how to specify NVRAM in anything other than a raw file. BTW: isn't qcow > too big gun for NVRAM? I mean, NVRAM has a fixed size of what ~190 KB? > QCOW header is about the same size. > > > <qemu:arg value='-device'/> > > <qemu:arg value='tpm-tis,tpmdev=tpm-tpm0,id=tpm0'/> > > <qemu:arg value='-tpmdev'/> > > <qemu:arg value='libtpms,id=tpm-tpm0,nvram=nvram0-0-0,startup=clear'/> > > I'm not sure there's a way how to put startup=clean on the cmd line. I'm > not even sure what it does. > And I have not idea what libtpms is either :-) > > > <qemu:arg value='-bios'/> > > <qemu:arg value='/root/xenSeabios/out/bios.bin'/> > > </qemu:commandline> > > On top of all that - QEMU is likely to fail to start since libvirt by default runs it as qemu:qemu user/group, and so it won't have permission to read any of the files in /root. If you have selinux/apparmour that will also block permission. This is an example of why usage of qemu:commandline is discouraged - it will always have problems with permissions if you pass files using it. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|

1 0