March 2020 - Devel - libvirt List Archives

[libvirt] [PATCH v4 0/2] introduction of migration_version attribute for VFIO live migration
by Yan Zhao 25 Mar '20

25 Mar '20

This patchset introduces a migration_version attribute under sysfs of VFIO Mediated devices. This migration_version attribute is used to check migration compatibility between two mdev devices of the same mdev type. Patch 1 defines migration_version attribute in Documentation/vfio-mediated-device.txt Patch 2 uses GVT as an example to show how to expose migration_version attribute and check migration compatibility in vendor driver. v4: 1. fixed indentation/spell errors, reworded several error messages 2. added a missing memory free for error handling in patch 2 v3: 1. renamed version to migration_version 2. let errno to be freely defined by vendor driver 3. let checking mdev_type be prerequisite of migration compatibility check 4. reworded most part of patch 1 5. print detailed error log in patch 2 and generate migration_version string at init time v2: 1. renamed patched 1 2. made definition of device version string completely private to vendor driver 3. reverted changes to sample mdev drivers 4. described intent and usage of version attribute more clearly. Yan Zhao (2): vfio/mdev: add migration_version attribute for mdev device drm/i915/gvt: export migration_version to mdev sysfs for Intel vGPU Documentation/vfio-mediated-device.txt | 113 +++++++++++++ drivers/gpu/drm/i915/gvt/Makefile | 2 +- drivers/gpu/drm/i915/gvt/gvt.c | 39 +++++ drivers/gpu/drm/i915/gvt/gvt.h | 5 + drivers/gpu/drm/i915/gvt/migration_version.c | 168 +++++++++++++++++++ drivers/gpu/drm/i915/gvt/vgpu.c | 13 +- 6 files changed, 337 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/i915/gvt/migration_version.c -- 2.17.1

3 9

[libvirt PATCH] docs: news: fix typo
by Ján Tomko 24 Mar '20

24 Mar '20

s/ommited/omitted/ Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- Pushed as trivial docs/news.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/news.xml b/docs/news.xml index 504cf52738..bcec1d81e9 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -51,7 +51,7 @@ <description> QEMU 5.0 implements NVDIMM memory support for pSeries guests. This is done by adding an 'uuid' element in the memory XML, which can - either be provided in the XML or, if ommited, generated + either be provided in the XML or, if omitted, generated automatically. </description> </change> -- 2.25.1

1 0

[PATCH] qemu: softfail for TCG capabilities probe
by Tobin Feldman-Fitzthum 24 Mar '20

24 Mar '20

As of version 2.10, QEMU can be built without the TCG. When libvirt determines that capabilities of a QEMU binary using QMP, it launches a QEMU process with KVM acceleration and TCG as a fallback. If QEMU supports KVM, a second probe is performed, forcing QEMU to use only TCG. This causes an error if the QEMU binary was built without TCG. This patch allows execution to continue when the second probe fails. Thus libvirt can be used with QEMU built without TCG. First patch. Feedback appreciated. If better solution, please advise. Signed-off-by: Tobin Feldman-Fitzthum <tobin(a)linux.vnet.ibm.com> --- src/qemu/qemu_capabilities.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index a95a60c36a..f303171cc4 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -5100,9 +5100,6 @@ virQEMUCapsInitQMPSingle(virQEMUCapsPtr qemuCaps, ret = virQEMUCapsInitQMPMonitor(qemuCaps, proc->mon); cleanup: - if (ret < 0) - virQEMUCapsLogProbeFailure(qemuCaps->binary); - qemuProcessQMPFree(proc); return ret; } @@ -5114,17 +5111,18 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps, uid_t runUid, gid_t runGid) { - if (virQEMUCapsInitQMPSingle(qemuCaps, libDir, runUid, runGid, false) < 0) + if (virQEMUCapsInitQMPSingle(qemuCaps, libDir, runUid, runGid, false) < 0) { + virQEMUCapsLogProbeFailure(qemuCaps->binary); return -1; + } /* * If KVM was enabled during the first probe, we need to explicitly probe * for TCG capabilities by asking the same binary again and turning KVM * off. */ - if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) && - virQEMUCapsInitQMPSingle(qemuCaps, libDir, runUid, runGid, true) < 0) - return -1; + if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM)) + virQEMUCapsInitQMPSingle(qemuCaps, libDir, runUid, runGid, true); return 0; } -- 2.20.1 (Apple Git-117)

2 1

[libvirt PATCH 0/5] gitlab: expand the CI job coverage (RESEND)
by Daniel P. Berrangé 24 Mar '20

24 Mar '20

There are two main goals with this series - Introduce a minimal job building the website and publishing an artifact which can be deployed onto libvirt.org - Expanding CI jobs to get coverage closer to Travis/Jenkins Previous posting lost last two mails due to transient SMTP problem Daniel P. Berrangé (5): gitlab: use CI for building website contents gitlab: reduce number of cross-build CI jobs gitlab: group jobs into stages gitlab: add several native CI jobs gitlab: rename the cross build jobs .gitlab-ci.yml | 105 +++++++++++++++++++++++++++++++++++-------------- 1 file changed, 75 insertions(+), 30 deletions(-) -- 2.24.1

3 29

[PATCH v1 0/4] Prevent ppc64 guest launch with broken features
by Daniel Henrique Barboza 24 Mar '20

24 Mar '20

Hi, This work was intended to fix a bug with APIC-EOI setting only (patch 1). I decided to take a closer look and ended up handling more cases. I consider the first 3 patches to be straightforward: those are conditions that QEMU will complain about and I'm simply refusing to launch while giving a better error message than the one QEMU provides. Patch 4 is more debatable. <hyperv><hyperv/> declaration in the XML is benign, but any of the 14 features being declared will cause QEMU errors. Instead of putting more code (i.e. a switch with 14 features in the middle of the code) to prevent any of those features to be enabled, I made a call to simply refuse to launch with any <hyperv> setting in the XML. This is not because I have a beef with Windows or MS or anything. This is about making an educated guess that it's highly unlikable that anyone is running ppc64 guests with <hyperv> declared in the XML, and it's not worth all the code to support it. But I'm all ears to hear otherwise. After this series, these are the features that aren't supported by ppc64 but can be declared in a ppc64 guest without resulting in a failed launch: <features> <acpi/> <apic/> (without 'eoi' setting) <pae/> <hap state='on|off'/> <viridian/> </features> Daniel Henrique Barboza (4): qemu_domain.c: do not launch ppc64 guests with APIC-EOI setting qemu_domain.c: do not launch ppc64 guests with 'pvspinlock' setting qemu_domain.c: do not launch ppc64 guests with 'pmu' setting qemu_domain.c: do not launch ppc64 guests with Hyperv settings src/qemu/qemu_domain.c | 49 ++++++++++++++++++++++++++++++++++++++---- 1 file changed, 45 insertions(+), 4 deletions(-) -- 2.25.1

3 18

[PATCH] qemu_monitor_text.c: Use g_autofree
by Seeteena Thoufeek 24 Mar '20

24 Mar '20

Signed-off-by: Seeteena Thoufeek <s1seetee(a)linux.vnet.ibm.com> --- src/qemu/qemu_monitor_text.c | 85 ++++++++++++++++---------------------------- 1 file changed, 30 insertions(+), 55 deletions(-) diff --git a/src/qemu/qemu_monitor_text.c b/src/qemu/qemu_monitor_text.c index 9135a11..5a890af 100644 --- a/src/qemu/qemu_monitor_text.c +++ b/src/qemu/qemu_monitor_text.c @@ -36,27 +36,26 @@ VIR_LOG_INIT("qemu.qemu_monitor_text"); int qemuMonitorTextAddDrive(qemuMonitorPtr mon, const char *drivestr) { - char *cmd = NULL; - char *reply = NULL; - int ret = -1; + g_autofree char *cmd = NULL; + g_autofree char *reply = NULL; /* 'dummy' here is just a placeholder since there is no PCI * address required when attaching drives to a controller */ cmd = g_strdup_printf("drive_add dummy %s", drivestr); if (qemuMonitorJSONHumanCommand(mon, cmd, &reply) < 0) - goto cleanup; + return -1; if (strstr(reply, "unknown command:")) { virReportError(VIR_ERR_OPERATION_FAILED, "%s", _("drive hotplug is not supported")); - goto cleanup; + return -1; } if (strstr(reply, "could not open disk image")) { virReportError(VIR_ERR_OPERATION_FAILED, "%s", _("open disk image file failed")); - goto cleanup; + return -1; } if (strstr(reply, "Could not open")) { @@ -66,48 +65,41 @@ int qemuMonitorTextAddDrive(qemuMonitorPtr mon, virReportError(VIR_ERR_OPERATION_FAILED, "%s", reply); - goto cleanup; + return -1; } if (strstr(reply, "Image is not in")) { virReportError(VIR_ERR_OPERATION_FAILED, "%s", _("Incorrect disk format")); - goto cleanup; + return -1; } if (strstr(reply, "IOMMU") || strstr(reply, "VFIO")) { virReportError(VIR_ERR_OPERATION_FAILED, "%s", reply); - goto cleanup; + return -1; } - ret = 0; - - cleanup: - VIR_FREE(cmd); - VIR_FREE(reply); - return ret; + return 0; } int qemuMonitorTextDriveDel(qemuMonitorPtr mon, const char *drivestr) { - char *cmd = NULL; - char *reply = NULL; - int ret = -1; + g_autofree char *cmd = NULL; + g_autofree char *reply = NULL; cmd = g_strdup_printf("drive_del %s", drivestr); if (qemuMonitorJSONHumanCommand(mon, cmd, &reply) < 0) - goto cleanup; + return -1; if (strstr(reply, "unknown command:")) { VIR_ERROR(_("deleting drive is not supported. " "This may leak data if disk is reassigned")); - ret = 1; - goto cleanup; + return 1; /* (qemu) drive_del wark * Device 'wark' not found */ @@ -117,15 +109,10 @@ int qemuMonitorTextDriveDel(qemuMonitorPtr mon, } else if (STRNEQ(reply, "")) { virReportError(VIR_ERR_OPERATION_FAILED, _("deleting %s drive failed: %s"), drivestr, reply); - goto cleanup; + return -1; } - ret = 0; - - cleanup: - VIR_FREE(cmd); - VIR_FREE(reply); - return ret; + return 0; } int @@ -159,28 +146,27 @@ qemuMonitorTextCreateSnapshot(qemuMonitorPtr mon, int qemuMonitorTextLoadSnapshot(qemuMonitorPtr mon, const char *name) { - char *cmd = NULL; - char *reply = NULL; - int ret = -1; + g_autofree char *cmd = NULL; + g_autofree char *reply = NULL; cmd = g_strdup_printf("loadvm \"%s\"", name); if (qemuMonitorJSONHumanCommand(mon, cmd, &reply)) - goto cleanup; + return -1; if (strstr(reply, "No block device supports snapshots")) { virReportError(VIR_ERR_OPERATION_INVALID, "%s", _("this domain does not have a device to load snapshots")); - goto cleanup; + return -1; } else if (strstr(reply, "Could not find snapshot")) { virReportError(VIR_ERR_OPERATION_INVALID, _("the snapshot '%s' does not exist, and was not loaded"), name); - goto cleanup; + return -1; } else if (strstr(reply, "Snapshots not supported on device")) { virReportError(VIR_ERR_OPERATION_INVALID, _("Failed to load snapshot: %s"), reply); - goto cleanup; + return -1; } else if (strstr(reply, "Could not open VM state file") || strstr(reply, "Error: ") || (strstr(reply, "Error") && @@ -188,46 +174,35 @@ int qemuMonitorTextLoadSnapshot(qemuMonitorPtr mon, const char *name) strstr(reply, "while activating snapshot on")))) { virReportError(VIR_ERR_OPERATION_FAILED, _("Failed to load snapshot: %s"), reply); - goto cleanup; + return -1; } - ret = 0; - - cleanup: - VIR_FREE(cmd); - VIR_FREE(reply); - return ret; + return 0; } int qemuMonitorTextDeleteSnapshot(qemuMonitorPtr mon, const char *name) { - char *cmd = NULL; - char *reply = NULL; - int ret = -1; + g_autofree char *cmd = NULL; + g_autofree char *reply = NULL; cmd = g_strdup_printf("delvm \"%s\"", name); if (qemuMonitorJSONHumanCommand(mon, cmd, &reply)) - goto cleanup; + return -1; if (strstr(reply, "No block device supports snapshots")) { virReportError(VIR_ERR_OPERATION_INVALID, "%s", _("this domain does not have a device to delete snapshots")); - goto cleanup; + return -1; } else if (strstr(reply, "Snapshots not supported on device")) { virReportError(VIR_ERR_OPERATION_INVALID, "%s", reply); - goto cleanup; + return -1; } else if (strstr(reply, "Error: ") || (strstr(reply, "Error") && strstr(reply, "while deleting snapshot"))) { virReportError(VIR_ERR_OPERATION_FAILED, _("Failed to delete snapshot: %s"), reply); - goto cleanup; + return -1; } - ret = 0; - - cleanup: - VIR_FREE(cmd); - VIR_FREE(reply); - return ret; + return 0; } -- 1.8.3.1

3 2

[PATCH] commandtest: Fix test28 error detection
by Michal Privoznik 24 Mar '20

24 Mar '20

As a part of c799d150d5e9dae I've introduced a test case that tests whether passing error object between processes works. The test spawns a child which reports a system error, parent process then reads the error and compares with expected output. Problem with this approach is that error message contains stringified errno which is not portable. FreeBSD has generally different messages than Linux. Therefore, use g_strerror() to do the errno to string translation for us. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- tests/commandtest.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tests/commandtest.c b/tests/commandtest.c index f4a2c67c05..d5092b7dd0 100644 --- a/tests/commandtest.c +++ b/tests/commandtest.c @@ -1272,6 +1272,7 @@ test28(const void *unused G_GNUC_UNUSED) /* Not strictly a virCommand test, but this is the easiest place * to test this lower-level interface. */ virErrorPtr err; + g_autofree char *msg = g_strdup_printf("some error message: %s", g_strerror(ENODATA)); if (virProcessRunInFork(test28Callback, NULL) != -1) { fprintf(stderr, "virProcessRunInFork did not fail\n"); @@ -1285,10 +1286,10 @@ test28(const void *unused G_GNUC_UNUSED) if (!(err->code == VIR_ERR_SYSTEM_ERROR && err->domain == 0 && - STREQ(err->message, "some error message: No data available") && + STREQ(err->message, msg) && err->level == VIR_ERR_ERROR && STREQ(err->str1, "%s") && - STREQ(err->str2, "some error message: No data available") && + STREQ(err->str2, msg) && err->int1 == ENODATA && err->int2 == -1)) { fprintf(stderr, "Unexpected error object\n"); -- 2.24.1

2 1

[PATCH 0/6] Couple of qemu NS improvements
by Michal Privoznik 24 Mar '20

24 Mar '20

The most important patch is 6/6 which relies on 5/6. The rest is just a few small nits I've noticed and had stuck on my local branch. Michal Prívozník (6): qemuDomainCreateDeviceRecursive: Report error if mkdir() fails qemuDomainBuildNamespace: Try harder to remove temp directories qemuDomainBuildNamespace: Make @devPath const virfile: Handle directories in virFileBindMountDevice() virprocess: Passthru error from virProcessRunInForkHelper security: Try harder to run transactions build-aux/syntax-check.mk | 2 +- src/qemu/qemu_domain.c | 13 +++++++-- src/security/security_dac.c | 16 ++++++++--- src/security/security_selinux.c | 16 ++++++++--- src/util/virfile.c | 13 +++++++-- src/util/virprocess.c | 51 ++++++++++++++++++++++++++++++--- tests/commandtest.c | 43 +++++++++++++++++++++++++++ 7 files changed, 136 insertions(+), 18 deletions(-) -- 2.24.1

6 16

[PATCH 00/14] qemu: Fix 'backing store' string generator for -blockdev
by Peter Krempa 24 Mar '20

24 Mar '20

QEMU doesn't like the backing store string generated by libvirt with -blockdev. Luckily we are able to parse them back and with blockdev they would no longer be used by qemu directly. Fix the generator an da few issues noticed along. Peter Krempa (14): conf: rename 'namespace' property of struct _virStorageSourceNVMeDef qemublocktest: xml->json: Add test for NVMe virDomainDiskSourceNVMeFormat: Format only valid 'managed' values qemublocktest: xml->json: Refactor cleanup in test case functions testQemuDiskXMLToPropsValidateFileSrcOnly: Move together with rest of xml->json code qemuBlockGetBackingStoreString: Add 'pretty' argument testQemuDiskXMLToProps: Store all per-image data in one structure qemublocktest: Test backing store strings qemuBlockGetBackingStoreString: Remove 'ret' variable storage: Implement backing store support for "fat:" prefix qemuBlockGetBackingStoreString: Add extra wrapping object to JSON strings qemu: block: Extract formatting of cookie string qemuBlockGetBackingStoreString: Properly handle 'http/s' with cookies and others storage: Parse 'nvme' disk source properties from json:{} pseudo-uri src/conf/domain_conf.c | 17 +- src/hypervisor/virhostdev.c | 2 +- src/qemu/qemu_block.c | 64 +++-- src/qemu/qemu_block.h | 6 +- src/qemu/qemu_domain.c | 13 +- src/qemu/qemu_driver.c | 4 +- src/util/virstoragefile.c | 43 +++- src/util/virstoragefile.h | 2 +- tests/qemublocktest.c | 232 ++++++++++-------- .../qcow2-backing-qcow2-slice.json | 2 +- .../imagecreate/qcow2-backing-raw-slice.json | 2 +- .../xml2json/block-raw-noopts-srconly.json | 13 +- .../block-raw-reservations-srconly.json | 13 +- .../xml2json/dir-fat-cache-srconly.json | 15 +- .../xml2json/dir-fat-floppy-srconly.json | 15 +- .../xml2json/dir-fat-readonly-srconly.json | 15 +- ...ile-backing_basic-aio_threads-srconly.json | 68 +++-- ...acking_basic-cache-directsync-srconly.json | 68 +++-- ...file-backing_basic-cache-none-srconly.json | 68 +++-- ...le-backing_basic-cache-unsafe-srconly.json | 68 +++-- ...backing_basic-cache-writeback-srconly.json | 68 +++-- ...king_basic-cache-writethrough-srconly.json | 68 +++-- .../file-backing_basic-detect-srconly.json | 68 +++-- .../file-backing_basic-noopts-srconly.json | 52 ++-- ...le-backing_basic-unmap-detect-srconly.json | 68 +++-- ...le-backing_basic-unmap-ignore-srconly.json | 68 +++-- .../file-backing_basic-unmap-srconly.json | 68 +++-- .../xml2json/file-bochs-noopts-srconly.json | 13 +- .../xml2json/file-cloop-noopts-srconly.json | 13 +- .../xml2json/file-dmg-noopts-srconly.json | 13 +- .../xml2json/file-ploop-noopts-srconly.json | 13 +- ...cow2-backing-chain-encryption-srconly.json | 26 +- ...le-qcow2-backing-chain-noopts-srconly.json | 130 +++++++--- ...w2-backing-chain-unterminated-srconly.json | 26 +- .../xml2json/file-raw-aio_native-srconly.json | 13 +- .../xml2json/file-raw-luks-srconly.json | 13 +- .../xml2json/file-raw-noopts-srconly.json | 13 +- .../xml2json/file-vdi-noopts-srconly.json | 13 +- .../xml2json/file-vhd-noopts-srconly.json | 13 +- .../xml2json/file-vpc-noopts-srconly.json | 13 +- .../network-http-curlopts-srconly.json | 17 ++ .../xml2json/network-http-curlopts.json | 15 ++ .../xml2json/network-http-curlopts.xml | 20 ++ .../xml2json/network-http-noopts-srconly.json | 9 + .../xml2json/network-http-noopts.json | 14 ++ .../xml2json/network-http-noopts.xml | 15 ++ .../xml2json/network-nbd-tls-srconly.json | 19 +- ...w2-backing-chain-cache-unsafe-srconly.json | 69 ++++-- ...backing-chain-encryption_auth-srconly.json | 69 ++++-- .../xml2json/nvme-raw-noopts-srconly.json | 15 ++ .../xml2json/nvme-raw-noopts.json | 14 ++ .../xml2json/nvme-raw-noopts.xml | 13 + tests/virstoragetest.c | 10 + 53 files changed, 1226 insertions(+), 575 deletions(-) create mode 100644 tests/qemublocktestdata/xml2json/network-http-curlopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/network-http-curlopts.json create mode 100644 tests/qemublocktestdata/xml2json/network-http-curlopts.xml create mode 100644 tests/qemublocktestdata/xml2json/network-http-noopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/network-http-noopts.json create mode 100644 tests/qemublocktestdata/xml2json/network-http-noopts.xml create mode 100644 tests/qemublocktestdata/xml2json/nvme-raw-noopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/nvme-raw-noopts.json create mode 100644 tests/qemublocktestdata/xml2json/nvme-raw-noopts.xml -- 2.24.1

2 17

[PATCH RESEND 0/5] virCommand: fix approach to pidfiles
by Michal Privoznik 24 Mar '20

24 Mar '20

The original series doesn't apply cleanly anymore: https://www.redhat.com/archives/libvir-list/2020-March/msg00499.html Here's the rebased one. Michal Prívozník (5): virCommand: Actually acquire pidfile instead of just writing it qemuProcessStartManagedPRDaemon: Don't pass -f pidfile to the daemon qemuSlirpStop: Simplify helper kill qemuVirtioFSStop: Simplify daemon kill bridge_driver: Replace and drop networkKillDaemon docs/internals/command.html.in | 4 +- src/network/bridge_driver.c | 106 ++++++--------------------------- src/qemu/qemu_process.c | 9 --- src/qemu/qemu_slirp.c | 16 ++--- src/qemu/qemu_virtiofs.c | 21 +++---- src/util/vircommand.c | 56 ++++++++++++++--- tests/commanddata/test4.log | 1 + 7 files changed, 81 insertions(+), 132 deletions(-) -- 2.24.1

3 12