- Devel - libvirt List Archives

[libvirt] question about PCI new_id sysfs interface
by Jim Fehlig 11 Jul '16

11 Jul '16

After updating the dom0 kernel on one of my Xen test hosts, I noticed problems with PCI hostdev management. E.g # virsh nodedev-detach pci_0000_07_10_1 error: Failed to detach device pci_0000_07_10_1 error: Failed to add PCI device ID '8086 1520' to pciback: File exists It turns out there was a small interface change to new_id with the following commit to 3.16 kernel https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/driv… which now causes xen_pciback to fail writes of "vendorid productid" to new_id. e.g. # echo "8086 1520" > /sys/bus/pci/drivers/pciback/new_id -bash: echo: write error: File exists Interestingly, vfio doesn't encounter the same error # echo "8086 1520" > /sys/bus/pci/drivers/vfio-pci/new_id # echo $? 0 vfio-pci has: static struct pci_driver vfio_pci_driver = { .name = "vfio-pci", .id_table = NULL, /* only dynamic ids */ while xen-pciback has: static const struct pci_device_id pcistub_ids[] = { { .vendor = PCI_ANY_ID, .device = PCI_ANY_ID, .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, }, {0,}, }; static struct pci_driver xen_pcibk_pci_driver = { .name = "pciback", .id_table = pcistub_ids, So any vendor/device pair will match for xen-pciback, while none will match for vfio-pci. But after reading that commit and the associated thread, it is not clear to me how to best fix this. Options are 1. set .id_table to NULL for xen-pciback 2. drop using the new_id interface from libvirt 3. pass more values (subvendor, subdevice, class, etc) to the new_id interface I'm not sure what problems, if any, options 1 and 2 might cause. Option 2 seems the best approach since new_id seems to be a rather unsafe interface. Thanks for your opinions! Regards, Jim

5 8

[libvirt] [PATCH] virCommandExec: Report error if execve fails
by Michal Privoznik 11 Jul '16

11 Jul '16

In an unlikely event of execve() failing, the virCommandExec() function does not report any error, even though checks that are at the beginning of the function are verbose when failing. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/util/vircommand.c | 7 +++++- tests/commandtest.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 75 insertions(+), 1 deletion(-) diff --git a/src/util/vircommand.c b/src/util/vircommand.c index f5bd7af..3c67c90 100644 --- a/src/util/vircommand.c +++ b/src/util/vircommand.c @@ -2152,7 +2152,12 @@ int virCommandExec(virCommandPtr cmd) return -1; } - return execve(cmd->args[0], cmd->args, cmd->env); + execve(cmd->args[0], cmd->args, cmd->env); + + virReportSystemError(errno, + _("cannot execute binary %s"), + cmd->args[0]); + return -1; } #else int virCommandExec(virCommandPtr cmd ATTRIBUTE_UNUSED) diff --git a/tests/commandtest.c b/tests/commandtest.c index f433ad7..8dc57d7 100644 --- a/tests/commandtest.c +++ b/tests/commandtest.c @@ -1063,6 +1063,74 @@ static int test24(const void *unused ATTRIBUTE_UNUSED) return ret; } + +static int test25(const void *unused ATTRIBUTE_UNUSED) +{ + int ret = -1; + int pipeFD[2] = { -1, -1}; + int rv = 0; + ssize_t tries = 10; + pid_t pid; + + if (pipe(pipeFD) < 0) { + fprintf(stderr, "Unable to create pipe\n"); + goto cleanup; + } + + if (virSetNonBlock(pipeFD[0]) < 0) { + fprintf(stderr, "Unable to make read end of pipe nonblocking\n"); + goto cleanup; + } + + /* Now, fork and try to exec a nonexistent binary. */ + pid = fork(); + if (pid < 0) { + fprintf(stderr, "Unable to spawn child\n"); + goto cleanup; + } + + if (pid == 0) { + /* Child */ + virCommandPtr cmd = virCommandNew("some/nonexistent/binary"); + + rv = virCommandExec(cmd); + if (safewrite(pipeFD[1], (void *) &rv, sizeof(rv)) < 0) + fprintf(stderr, "Unable to write to pipe\n"); + _exit(EXIT_FAILURE); + } + + /* Parent */ + while (tries--) { + if (saferead(pipeFD[0], (void *) &rv, sizeof(rv)) < 0) { + if (errno != EWOULDBLOCK) { + fprintf(stderr, "Unable to read from pipe\n"); + goto cleanup; + } + + usleep(1000); + } else { + break; + } + } + + if (!tries) { + fprintf(stderr, "Child hasn't returned anything\n"); + goto cleanup; + } + + if (rv >= 0) { + fprintf(stderr, "Child should have returned an error\n"); + goto cleanup; + } + + ret = 0; + cleanup: + VIR_FORCE_CLOSE(pipeFD[0]); + VIR_FORCE_CLOSE(pipeFD[1]); + return ret; +} + + static void virCommandThreadWorker(void *opaque) { virCommandTestDataPtr test = opaque; @@ -1215,6 +1283,7 @@ mymain(void) DO_TEST(test22); DO_TEST(test23); DO_TEST(test24); + DO_TEST(test25); virMutexLock(&test->lock); if (test->running) { -- 2.8.4

2 2

[libvirt] [PATCHv2 0/3] qemu: add support for intel-iommu
by Ján Tomko 11 Jul '16

11 Jul '16

https://bugzilla.redhat.com/show_bug.cgi?id=1235581 v2: * removed '-iommu' suffix from the model name * mentioned the device in formatdomain.html * added the device to ABI stability check and the hot/coldplug parser (where both operations are rejected) * error out on non-q35 machines * added a comment about broken qemu to the commit message of patch 2/3 * no change wrt the device order on the command line - qemu seems to take care of this Ján Tomko (3): Introduce <iommu> device Add QEMU_CAPS_DEVICE_INTEL_IOMMU qemu: format intel-iommu on the command line docs/formatdomain.html.in | 26 +++++++ docs/schemas/domaincommon.rng | 11 +++ src/conf/domain_conf.c | 90 +++++++++++++++++++++- src/conf/domain_conf.h | 16 ++++ src/libvirt_private.syms | 2 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 35 +++++++++ src/qemu/qemu_driver.c | 6 ++ src/qemu/qemu_hotplug.c | 1 + tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-intel-iommu.args | 22 ++++++ .../qemuxml2argvdata/qemuxml2argv-intel-iommu.xml | 37 +++++++++ tests/qemuxml2argvtest.c | 2 + .../qemuxml2xmlout-intel-iommu.xml | 37 +++++++++ tests/qemuxml2xmltest.c | 4 + 18 files changed, 294 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-intel-iommu.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-intel-iommu.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-intel-iommu.xml -- 2.7.3

2 4

[libvirt] [PATCH 0/5] test-rewrap-args improvements
by Ján Tomko 11 Jul '16

11 Jul '16

Ján Tomko (5): qemuxml2argvtest: drop empty pseries-vio-address-clash.args testutils: find perl early testutils: only rewrap args files test-wrap-argv: print diff instead of the incorrectly wrapped file test-wrap-argv: set cutoff at 78 characters .../qemuargv2xml-disk-drive-cache-unsafe.args | 3 ++- .../qemuargv2xml-disk-drive-network-rbd-ipv6.args | 4 ++-- .../qemuxml2argv-aarch64-virt-default-nic.args | 3 ++- ...qemuxml2argv-aarch64-virtio-pci-manual-addresses.args | 4 ++-- .../qemuxml2argv-arm-vexpressa9-virtio.args | 3 ++- tests/qemuxml2argvdata/qemuxml2argv-autoindex.args | 4 ++-- tests/qemuxml2argvdata/qemuxml2argv-bios-nvram.args | 3 ++- .../qemuxml2argv-boot-complex-bootindex.args | 3 ++- .../qemuxml2argv-boot-menu-disable-drive-bootindex.args | 3 ++- .../qemuxml2argv-boot-menu-enable-bootindex.args | 3 ++- tests/qemuxml2argvdata/qemuxml2argv-boot-order.args | 3 ++- tests/qemuxml2argvdata/qemuxml2argv-boot-strict.args | 3 ++- .../qemuxml2argv-console-virtio-ccw.args | 4 ++-- .../qemuxml2argv-cpu-host-model-vendor.args | 4 ++-- .../qemuxml2argv-disk-cdrom-network-ftp.args | 4 ++-- .../qemuxml2argv-disk-cdrom-network-http.args | 4 ++-- .../qemuxml2argv-disk-cdrom-network-tftp.args | 4 ++-- .../qemuxml2argv-disk-drive-network-iscsi-lun.args | 8 ++++---- .../qemuxml2argv-disk-drive-network-iscsi.args | 4 ++-- .../qemuxml2argv-disk-drive-network-rbd-auth-AES.args | 5 +++-- .../qemuxml2argv-disk-drive-network-rbd-ipv6.args | 4 ++-- .../qemuxml2argv-disk-drive-no-boot.args | 6 ++++-- tests/qemuxml2argvdata/qemuxml2argv-disk-ioeventfd.args | 4 ++-- .../qemuxml2argv-disk-scsi-lun-passthrough.args | 8 ++++---- .../qemuxml2argvdata/qemuxml2argv-disk-scsi-megasas.args | 4 ++-- .../qemuxml2argv-disk-scsi-mptsas1068.args | 4 ++-- .../qemuxml2argv-disk-scsi-virtio-scsi.args | 4 ++-- tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-vscsi.args | 4 ++-- .../qemuxml2argv-disk-source-pool-mode.args | 4 ++-- .../qemuxml2argv-disk-virtio-ccw-many.args | 9 ++++++--- tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-ccw.args | 3 ++- .../qemuxml2argv-disk-virtio-scsi-ccw.args | 7 ++++--- .../qemuxml2argv-disk-virtio-scsi-cmd_per_lun.args | 4 ++-- .../qemuxml2argv-disk-virtio-scsi-ioeventfd.args | 4 ++-- .../qemuxml2argv-disk-virtio-scsi-max_sectors.args | 4 ++-- .../qemuxml2argv-disk-virtio-scsi-num_queues.args | 4 ++-- tests/qemuxml2argvdata/qemuxml2argv-fs9p-ccw.args | 3 ++- .../qemuxml2argvdata/qemuxml2argv-hostdev-scsi-boot.args | 4 ++-- .../qemuxml2argv-hostdev-scsi-lsi-iscsi.args | 4 ++-- .../qemuxml2argv-hostdev-scsi-readonly.args | 4 ++-- .../qemuxml2argv-hostdev-scsi-virtio-iscsi-auth.args | 8 ++++---- .../qemuxml2argv-hostdev-scsi-virtio-iscsi.args | 12 ++++++------ .../qemuxml2argv-hostdev-scsi-virtio-scsi.args | 4 ++-- tests/qemuxml2argvdata/qemuxml2argv-hugepages-pages.args | 3 ++- .../qemuxml2argvdata/qemuxml2argv-hugepages-pages2.args | 3 ++- .../qemuxml2argvdata/qemuxml2argv-hugepages-pages3.args | 3 ++- .../qemuxml2argvdata/qemuxml2argv-hugepages-pages5.args | 3 ++- .../qemuxml2argvdata/qemuxml2argv-hugepages-pages6.args | 3 ++- .../qemuxml2argvdata/qemuxml2argv-hugepages-shared.args | 7 ++++--- .../qemuxml2argv-iothreads-virtio-scsi-ccw.args | 4 ++-- .../qemuxml2argv-iothreads-virtio-scsi-pci.args | 4 ++-- .../qemuxml2argv-machine-aeskeywrap-off-cap.args | 3 ++- .../qemuxml2argv-machine-aeskeywrap-off-caps.args | 3 ++- .../qemuxml2argv-machine-aeskeywrap-on-cap.args | 3 ++- .../qemuxml2argv-machine-aeskeywrap-on-caps.args | 3 ++- .../qemuxml2argv-machine-deakeywrap-off-cap.args | 3 ++- .../qemuxml2argv-machine-deakeywrap-off-caps.args | 3 ++- .../qemuxml2argv-machine-deakeywrap-on-cap.args | 3 ++- .../qemuxml2argv-machine-deakeywrap-on-caps.args | 3 ++- .../qemuxml2argv-machine-keywrap-none-caps.args | 3 ++- .../qemuxml2argv-machine-keywrap-none.args | 3 ++- .../qemuxml2argv-memory-hotplug-dimm-addr.args | 3 ++- .../qemuxml2argv-memory-hotplug-dimm.args | 3 ++- tests/qemuxml2argvdata/qemuxml2argv-monitor-json.args | 4 ++-- tests/qemuxml2argvdata/qemuxml2argv-name-escape.args | 4 ++-- .../qemuxml2argv-net-vhostuser-multiq.args | 3 ++- tests/qemuxml2argvdata/qemuxml2argv-net-vhostuser.args | 3 ++- .../qemuxml2argv-net-virtio-disable-offloads.args | 8 ++++---- tests/qemuxml2argvdata/qemuxml2argv-no-shutdown.args | 4 ++-- .../qemuxml2argvdata/qemuxml2argv-pci-autoadd-addr.args | 4 ++-- tests/qemuxml2argvdata/qemuxml2argv-pci-autoadd-idx.args | 4 ++-- tests/qemuxml2argvdata/qemuxml2argv-pci-many.args | 4 ++-- .../qemuxml2argvdata/qemuxml2argv-pcie-expander-bus.args | 3 ++- .../qemuxml2argv-pseries-vio-address-clash.args | 0 .../qemuxml2argv-pseries-vio-user-assigned.args | 4 ++-- tests/qemuxml2argvdata/qemuxml2argv-pseries-vio.args | 4 ++-- tests/qemuxml2argvdata/qemuxml2argv-q35-usb2-multi.args | 4 ++-- .../qemuxml2argvdata/qemuxml2argv-q35-usb2-reorder.args | 4 ++-- .../qemuxml2argv-s390-allow-bogus-usb-controller.args | 4 ++-- .../qemuxml2argv-s390-allow-bogus-usb-none.args | 4 ++-- tests/qemuxml2argvdata/qemuxml2argv-virtio-rng-ccw.args | 4 ++-- tests/test-wrap-argv.pl | 16 ++++++++++------ tests/testutils.c | 16 +++++++++++++++- 83 files changed, 208 insertions(+), 151 deletions(-) delete mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-vio-address-clash.args -- 2.7.3

2 7

[libvirt] [PATCH 0/3] Clean up qemuhotplugtest xml files
by Tomasz Flendrich 11 Jul '16

11 Jul '16

I plan on doing bigger changes to qemuhotplugtest.c. It's going to test device attachment/detachment to both live (like now) and persistent (something that is missing now) domains. More files will be added, so I decided to clean up ones that are there now. Many files were not even connected to any qemuxml2argv test, and yet they were in tests/qemuxml2argvdata/ Tomasz Flendrich (3): Move all qemuhotplugtest XMLs to one directory Move domain and device xmls to different directories Use virschematest on qemuhotplugtest domain xmls tests/qemuhotplugtest.c | 52 ++++++------- .../qemuhotplug-console-virtio.xml | 0 .../qemuhotplug-disk-cdrom-nochange.xml | 0 .../qemuhotplug-disk-scsi-2.xml | 0 .../qemuhotplug-disk-scsi.xml | 0 .../qemuhotplug-disk-usb.xml | 0 .../qemuhotplug-disk-virtio.xml | 0 ...lug-graphics-spice-listen-network-password.xml} | 0 .../qemuhotplug-graphics-spice-listen.xml | 0 .../qemuhotplug-graphics-spice-nochange.xml | 0 ...qemuhotplug-graphics-spice-timeout-nochange.xml | 0 ...qemuhotplug-graphics-spice-timeout-password.xml | 0 .../qemuhotplug-qemu-agent-detach.xml | 0 .../qemuhotplug-qemu-agent.xml | 0 .../qemuhotplug-base+qemu-agent-detach.xml} | 0 .../qemuhotplug-base+qemu-agent.xml} | 0 .../qemuhotplug-base-live+disk-scsi.xml} | 0 .../qemuhotplug-base-live+disk-usb.xml} | 0 .../qemuhotplug-base-live+disk-virtio.xml} | 0 .../qemuhotplug-base-live+qemu-agent-detach.xml} | 0 .../qemuhotplug-base-live+qemu-agent.xml} | 0 .../qemuhotplug-base-live.xml} | 0 ...base-with-scsi-controller-live+disk-scsi-2.xml} | 0 ...qemuhotplug-base-with-scsi-controller-live.xml} | 0 ...e-without-scsi-controller-live+disk-scsi-2.xml} | 0 ...uhotplug-base-without-scsi-controller-live.xml} | 0 ...otplug-console-compat-2-live+console-virtio.xml | 0 .../qemuhotplug-console-compat-2-live.xml} | 0 .../qemuhotplug-disk-cdrom.xml | 37 +++++++++ .../qemuhotplug-graphics-spice-listen-network.xml} | 0 .../qemuhotplug-graphics-spice-timeout.xml | 87 ++++++++++++++++++++++ .../qemuhotplug-graphics-spice.xml | 47 ++++++++++++ tests/virschematest.c | 3 +- 33 files changed, 199 insertions(+), 27 deletions(-) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-console-virtio.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-disk-cdrom-nochange.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-disk-scsi-2.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-disk-scsi.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-disk-usb.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-disk-virtio.xml (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-graphics-spice-listen-network.xml => qemuhotplugtestdevices/qemuhotplug-graphics-spice-listen-network-password.xml} (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-graphics-spice-listen.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-graphics-spice-nochange.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-graphics-spice-timeout-nochange.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-graphics-spice-timeout-password.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-qemu-agent-detach.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-qemu-agent.xml (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-live+qemu-agent-detach.xml => qemuhotplugtestdomains/qemuhotplug-base+qemu-agent-detach.xml} (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-live+qemu-agent.xml => qemuhotplugtestdomains/qemuhotplug-base+qemu-agent.xml} (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-live+disk-scsi.xml => qemuhotplugtestdomains/qemuhotplug-base-live+disk-scsi.xml} (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-live+disk-usb.xml => qemuhotplugtestdomains/qemuhotplug-base-live+disk-usb.xml} (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-live+disk-virtio.xml => qemuhotplugtestdomains/qemuhotplug-base-live+disk-virtio.xml} (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base+qemu-agent-detach.xml => qemuhotplugtestdomains/qemuhotplug-base-live+qemu-agent-detach.xml} (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base+qemu-agent.xml => qemuhotplugtestdomains/qemuhotplug-base-live+qemu-agent.xml} (100%) rename tests/{qemuxml2argvdata/qemuxml2argv-hotplug-base-live.xml => qemuhotplugtestdomains/qemuhotplug-base-live.xml} (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-with-scsi-controller-live+disk-scsi-2.xml => qemuhotplugtestdomains/qemuhotplug-base-with-scsi-controller-live+disk-scsi-2.xml} (100%) rename tests/{qemuxml2argvdata/qemuxml2argv-hotplug-base-with-scsi-controller-live.xml => qemuhotplugtestdomains/qemuhotplug-base-with-scsi-controller-live.xml} (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-without-scsi-controller-live+disk-scsi-2.xml => qemuhotplugtestdomains/qemuhotplug-base-without-scsi-controller-live+disk-scsi-2.xml} (100%) rename tests/{qemuxml2argvdata/qemuxml2argv-hotplug-base-without-scsi-controller-live.xml => qemuhotplugtestdomains/qemuhotplug-base-without-scsi-controller-live.xml} (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdomains}/qemuhotplug-console-compat-2-live+console-virtio.xml (100%) rename tests/{qemuxml2argvdata/qemuxml2argv-console-compat-2-live.xml => qemuhotplugtestdomains/qemuhotplug-console-compat-2-live.xml} (100%) create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-disk-cdrom.xml rename tests/{qemuxml2argvdata/qemuxml2argv-graphics-spice-listen-network.xml => qemuhotplugtestdomains/qemuhotplug-graphics-spice-listen-network.xml} (100%) create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-graphics-spice-timeout.xml create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-graphics-spice.xml -- 2.7.4 (Apple Git-66)

2 1

[libvirt] [PATCH 0/5] Couple of memleaks fixes
by Michal Privoznik 11 Jul '16

11 Jul '16

I've found these while procrastinating on friday afternoon. Michal Privoznik (5): virStorageEncryptionSecretFree: Don't leak secret lookup definition qemuBuildCpuCommandLine: Don't leak @buf qemuDomainObjPrivateFree: Free @masterKey too qemuxml2argvtest: Don't leak dummy monitor qemuxml2argvmock: Don't leak @netdef->ifname src/qemu/qemu_command.c | 1 + src/qemu/qemu_domain.c | 21 +++++++++++++++------ src/util/virstorageencryption.c | 1 + tests/qemuxml2argvmock.c | 1 + tests/qemuxml2argvtest.c | 5 +++-- 5 files changed, 21 insertions(+), 8 deletions(-) -- 2.8.4

2 10

[libvirt] [PATCH v3] virsh: allow both --uuid and --name at same time
by Chen Hanxiao 11 Jul '16

11 Jul '16

From: Chen Hanxiao <chenhanxiao(a)gmail.com> #virsh list --uuid --name 49c765a0-25e7-40d0-964f-dac99724b32c c7 918f1dd6-b19f-412b-ba17-d113bad89af8 f23 Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- v3: add virsh.pod sections v2: drop uuid-name option, enable both --uuid and --name tools/virsh-domain-monitor.c | 14 ++++++++------ tools/virsh.pod | 10 ++++++++-- 2 files changed, 16 insertions(+), 8 deletions(-) diff --git a/tools/virsh-domain-monitor.c b/tools/virsh-domain-monitor.c index 0a93949..c712fa5 100644 --- a/tools/virsh-domain-monitor.c +++ b/tools/virsh-domain-monitor.c @@ -1844,12 +1844,8 @@ cmdList(vshControl *ctl, const vshCmd *cmd) FILTER("state-shutoff", VIR_CONNECT_LIST_DOMAINS_SHUTOFF); FILTER("state-other", VIR_CONNECT_LIST_DOMAINS_OTHER); - if (optTable + optName + optUUID > 1) { - vshError(ctl, "%s", - _("Only one argument from --table, --name and --uuid " - "may be specified.")); - return false; - } + VSH_EXCLUSIVE_OPTIONS("table", "name"); + VSH_EXCLUSIVE_OPTIONS("table", "uuid"); if (!optUUID && !optName) optTable = true; @@ -1907,6 +1903,12 @@ cmdList(vshControl *ctl, const vshCmd *cmd) state == -2 ? _("saved") : virshDomainStateToString(state)); } + } else if (optUUID && optName) { + if (virDomainGetUUIDString(dom, uuid) < 0) { + vshError(ctl, "%s", _("Failed to get domain's UUID")); + goto cleanup; + } + vshPrint(ctl, "%-36s %-30s\n", uuid, virDomainGetName(dom)); } else if (optUUID) { if (virDomainGetUUIDString(dom, uuid) < 0) { vshError(ctl, "%s", _("Failed to get domain's UUID")); diff --git a/tools/virsh.pod b/tools/virsh.pod index 601cb44..d7cd10e 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -524,8 +524,14 @@ Note that this flag does not filter the list of domains. If I<--name> is specified, domain names are printed instead of the table formatted one per line. If I<--uuid> is specified domain's UUID's are printed instead of names. Flag I<--table> specifies that the legacy table-formatted -output should be used. This is the default. All of these are mutually -exclusive. +output should be used. This is the default. + +If both I<--name> and I<--uuid> are specified, domain UUID's and names +are printed side by side without any header. Flag I<--table> specifies +that the legacy table-formatted output should be used. This is the +default if neither I<--name> nor I<--uuid> are specified. Options +I<--uuid> and I<--name> are mutually exclusive if option I<--table> is +specified. If I<--title> is specified, then the short domain description (title) is printed in an extra column. This flag is usable only with the default -- 1.8.3.1

2 1

[libvirt] [PATCH RFC 0/5] libxl: host cpu element in capabilities
by Joao Martins 11 Jul '16

11 Jul '16

Hey! This series is the RFC I mentioned in cpu map discussion for libxl[0]. That is to implement host.cpu element in caps,by getting topology and xen hwcaps parsing done, followed by having cpu-{compare,baseline} and get cpu models APIs implemented. Last thing missing I think it would be to libxl_cpuid_set the features to enable/disable whichever format we choose plus the appropriate XML convertion to/from XM and XL config formats. Cheers, Joao [0] https://www.redhat.com/archives/libvir-list/2016-July/msg00237.html Joao Martins (5): libxl: describe host topology in capabilities libxl: describe host cpu features based on hwcaps libxl: implement virConnectCompareCPU libxl: implement virConnectBaselineCPU libxl: implement virConnectGetCPUModelNames src/libxl/libxl_capabilities.c | 148 ++++++++++++++++++++++++++++++++++++++--- src/libxl/libxl_driver.c | 74 +++++++++++++++++++++ 2 files changed, 212 insertions(+), 10 deletions(-) -- 2.1.4

2 7

[libvirt] [PATCH] libvirt.spec.in: soft-static allocation of qemu and kvm groups
by Jaroslav Suchanek 11 Jul '16

11 Jul '16

Follow the same logic for adding qemu user also for kvm and qemu groups. As is described in https://fedoraproject.org/wiki/Packaging:UsersAndGroups document there should be preallocated UIDs and GIDs for libvirt. A check for required group id was added prior groupadd execution. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1351792 --- libvirt.spec.in | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 2b98836..3dc3193 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1464,8 +1464,20 @@ fi # We want soft static allocation of well-known ids, as disk images # are commonly shared across NFS mounts by id rather than name; see # https://fedoraproject.org/wiki/Packaging:UsersAndGroups -getent group kvm >/dev/null || groupadd -f -g 36 -r kvm -getent group qemu >/dev/null || groupadd -f -g 107 -r qemu +if ! getent group kvm >/dev/null; then + if ! getent group 36 >/dev/null; then + groupadd -f -g 36 -r kvm + else + groupadd -f -r kvm + fi +fi +if ! getent group qemu >/dev/null; then + if ! getent group 107 >/dev/null; then + groupadd -f -g 107 -r qemu + else + groupadd -f -r qemu + fi +fi if ! getent passwd qemu >/dev/null; then if ! getent passwd 107 >/dev/null; then useradd -r -u 107 -g qemu -G kvm -d / -s /sbin/nologin -c "qemu user" qemu -- 1.8.3.1

2 2

Re: [libvirt] [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features
by David Hildenbrand 11 Jul '16

11 Jul '16

Are there any further comments, especially on patches 23-25, introducing new QOM interfaces? Also, if anybody is planning to look into this, please speak up :) Otherwise it might make sense to put this onto the next KVM call agenda. David > This is our second attempt to implement CPU models for s390x. We realized > that we also want to have features exposed via the CPU model. While doing > that we realized that we want to have a better interface for libvirt. > > Unfortunately, CPU models on s390x are special and we have to take care of: > - A CPU like z13 looks differently in various environments (under different > LPAR versions, under different z/VM versions, under different KVM > versions, export regulation) - we have _a lot_ of feature variability. > - We still have certain features that are not published but might be > implemented/introduced in the future. As they are a theoretical part > of a CPU already, we have to find a way to model these future changes. > - We still have certain features that are already published, but not > implemented. Implementation might be added in the future in KVM. > - We heavily rely on KVM to tell us which features it can actually > virtualize - user space queries like "STFL(e)" give no guarantees. > - Certain "subfeatures" were introduced in one run. In practice, they are > always around, but in theory, subfeatures could be dropped in the future. > - Just because two CPU models have the same features doesn't mean they > are equal - some internal numbers might be different. E.g. we won't allow > running a z13 under a zBC12 just by turning off features. > - We cannot blindly enable all possible features for a CPU generation, > the IBC "Instruction Blocking Control" in KVM will try to block > instructions introduced with certain features. So a CPU generation always > has some maximum feature set that is guaranteed to work. > > It all boils down to a specific released CPU to have. > a) A fixed feature set that we expect it to be have on every hypervisor. > b) A variable part that depends on the hypervisor and that could be > extended in the future (adding not yet implemented features) that we > always want to enable later on. > c) A variable part that we want to enable only if requested - nested > virtualization ("vsie") and assists are one example. > > But, the fixed feature set is not really what we want to use as a default. > It is just like a really minimum, stable base. > > So we have > a) A "stable" CPU model for each released CPU that will never change and > maps to the minimum feature set we expect to be around on all > hypervisors. e.g. "z13-base" or "z10EC.2-base". These are migration > safe. > b) A "default" CPU model for each released CPU, that can change between > QEMU versions and that will always include the features we expect to > be around in our currently supported environments and will contain only > features we expect to be stable. E.g. nested virtualization will not be > contained in these models. These models are not migration safe, e.g > "z13" or "z10EC.2". The feature set can differ between QEMU versions. > c) An internal "maximum" CPU model for each generation that tells us which > features were supported as a maximum back when the hardware was > released. This will not be exposed > > To not have to replicate all CPU model changes ("new default fetaures") in > libvirt, to not duplicate the logic about compatibility and the like, > our approach tries to keep all the QEMU logic in libvirt and provide > standardized interfaces for libvirt to e.g. baseline, compare. This > allows libvirt to not have to care about any model names or feature names, > it can just pass the data from interface to interface and report it to > the user. > > Also, libvirt might want to know what the "host" model looks like and > convert a CPU model to a migration safe variant. For this reason, a QMP > command is added that can create a migration safe variant of a variable > CPU model, indicating only the delta changes done to a stable model. > > So we have: > a) "query-cpu-model-expansion" - tell us what the "host" or a migration > unsafe model looks like. Either falling back to a stable model or > completely exposing all properties. We are interested in stable models. > b) "query-cpu-model-comparison" - tell us how two CPU models compare, > indicating which properties were responsible for the decision. > c) "query-cpu-model-baseline" - create a new model out of two models, > taking a requested level of stability into account. > > As we are aware that e.g. x86 has their own idea of a CPU model and their > existing implementation in place, but are also looking into to ways to e.g. > expand the "host" CPU model to a detailed representation, we designed the > "expansion" interface to also allow that. > > Comments are very welcome, but please always keep the restrictions and > specialties in mind when suggesting some major design changes. > > The header update will be replaced by a kvm-next header update as soon as > the VSIE patches are upstream. The major KVM interface changes are already > part of kvm-next. > > The current state is available on git://github.com/cohuck/qemu on branch > "cpumodel-s390x". > > David Hildenbrand (26): > s390x/cpumodel: "host" and "qemu" as CPU subclasses > s390x/cpumodel: expose CPU class properties > s390x/cpumodel: generate CPU feature group lists > s390x/cpumodel: introduce CPU feature group definitions > s390x/cpumodel: register defined CPU models as subclasses > s390x/cpumodel: store the CPU model in the CPU instance > s390x/cpumodel: expose features and feature groups as properties > s390x/cpumodel: let the CPU model handle feature checks > s390x/cpumodel: check and apply the CPU model > s390x/sclp: factor out preparation of cpu entries > s390x/sclp: introduce sclp feature blocks > s390x/sclp: indicate sclp features > s390x/sclp: propagate the ibc val(lowest and unblocked ibc) > s390x/sclp: propagate the mha via sclp > s390x/sclp: propagate hmfai > update linux headers (CPU model) > s390x/kvm: allow runtime-instrumentation for "none" machine > s390x/kvm: implement CPU model support > s390x/kvm: disable host model for existing compat machines > s390x/kvm: let the CPU model control CMM(A) > qmp: add QMP interface "query-cpu-model-expansion" > qmp: add QMP interface "query-cpu-model-comparison" > qmp: add QMP interface "query-cpu-model-baseline" > s390x/cpumodel: implement QMP interface "query-cpu-model-expansion" > s390x/cpumodel: implement QMP interface "query-cpu-model-comparison" > s390x/cpumodel: implement QMP interface "query-cpu-model-baseline" > > Michael Mueller (2): > s390x/cpumodel: introduce CPU features > s390x/cpumodel: generate CPU feature lists for CPU models > > Makefile.target | 2 +- > hw/s390x/s390-virtio-ccw.c | 5 + > hw/s390x/s390-virtio.c | 6 +- > hw/s390x/sclp.c | 35 +- > include/hw/s390x/sclp.h | 17 +- > include/sysemu/arch_init.h | 10 + > linux-headers/asm-s390/kvm.h | 40 ++ > qapi-schema.json | 184 ++++++ > qmp-commands.hx | 18 + > qmp.c | 22 + > rules.mak | 1 + > stubs/Makefile.objs | 3 + > stubs/arch-query-cpu-model-baseline.c | 13 + > stubs/arch-query-cpu-model-comparison.c | 12 + > stubs/arch-query-cpu-model-expansion.c | 12 + > target-s390x/Makefile.objs | 22 +- > target-s390x/cpu-qom.h | 5 + > target-s390x/cpu.c | 35 +- > target-s390x/cpu.h | 5 + > target-s390x/cpu_features.c | 376 +++++++++++ > target-s390x/cpu_features.h | 302 +++++++++ > target-s390x/cpu_models.c | 1055 +++++++++++++++++++++++++++++++ > target-s390x/cpu_models.h | 113 ++++ > target-s390x/gen-features.c | 587 +++++++++++++++++ > target-s390x/helper.c | 29 +- > target-s390x/kvm.c | 346 +++++++++- > target-s390x/machine.c | 14 +- > 27 files changed, 3203 insertions(+), 66 deletions(-) > create mode 100644 stubs/arch-query-cpu-model-baseline.c > create mode 100644 stubs/arch-query-cpu-model-comparison.c > create mode 100644 stubs/arch-query-cpu-model-expansion.c > create mode 100644 target-s390x/cpu_features.c > create mode 100644 target-s390x/cpu_features.h > create mode 100644 target-s390x/cpu_models.c > create mode 100644 target-s390x/cpu_models.h > create mode 100644 target-s390x/gen-features.c >

2 2