- Devel - libvirt List Archives

[libvirt] [PATCH] maint: Add support for .ctags.d
by Jiri Denemark 31 May '19

31 May '19

Depending on the way ctags was compiled, it may look for .ctags.d/*.ctags files rather than .ctags for reading configuration. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- .ctags.d/libvirt.ctags | 1 + 1 file changed, 1 insertion(+) create mode 120000 .ctags.d/libvirt.ctags diff --git a/.ctags.d/libvirt.ctags b/.ctags.d/libvirt.ctags new file mode 120000 index 0000000000..eefd37f401 --- /dev/null +++ b/.ctags.d/libvirt.ctags @@ -0,0 +1 @@ +../.ctags \ No newline at end of file -- 2.21.0

2 1

[libvirt] [PATCH 0/2] news: Update for 5.4.0 release
by Andrea Bolognani 31 May '19

31 May '19

Hopefully I've done a decent enough job at summarizing, especially with the security stuff: if not, please let me know! Andrea Bolognani (2): news: Reformat overgrown line news: Update for 5.4.0 release docs/news.xml | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 60 insertions(+), 1 deletion(-) -- 2.21.0

2 3

[libvirt] Entering freeze for libvirt 5.4.0
by Daniel Veillard 31 May '19

31 May '19

This is tagged in git, I have put the signed tarball and source RPM at the usual place: https://libvirt.org/sources/ I did not build the binaries rpms, first it broke because I was still on F28 c.f. Jan's patch, and second it's true to provides little value, it's doubtful people would just install my binaries as is. Will likely stick to sources as part of releases in the future. Release looks fine in my limited testing, https://ci.centos.org/view/libvirt/ is of a rare uniform green color, which is promising too ! Please give it a try, I will likely cut RC2 on Thrusday, and then if everything goes fine push the GA over the w.e. or Monday, thanks, Daniel -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

1 1

[libvirt] Question about save and restore OVS per-port data in live migration
by wangxin (U) 31 May '19

31 May '19

Hi When we try to migrate a guest with 12 NICs, we find libvirt will try to get per-port data in finish phase, it makes the guest paused for several hundred milliseconds. qemuMigrationCookieAddNetwork -> virNetDevOpenvswitchGetMigrateData for per-nic -> run 'ovs-vsctl --if-exists get Interface vnetx external_ids:Port' (about 25ms) In our case, there's no portData available and it seems there is no need to run the cmd. Questions: 1. Is it necessary to get/set per-port data in migration finish phase? It will increase the downtime. 2. Is there any way (i.e. a switch) to not run the OVS cmd if there's no portData available?

2 4

[libvirt] [PATCH] docs: Replace the SEV links with a single one to AMD's document store
by Erik Skultety 31 May '19

31 May '19

The SEV whitepaper link stopped working as the resource has been moved. But all the SEV-related stuff like spec, whitepaper, presentations, etc. are being provided at https://developer.amd.com/sev/ which may look like a more stable resource (in terms of not being removed in the foreseeable future) so rather than providing and maintaining links to individual resources, let's use this one instead. Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- docs/formatdomaincaps.html.in | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in index 432d7aed5e..ef42bd57c3 100644 --- a/docs/formatdomaincaps.html.in +++ b/docs/formatdomaincaps.html.in @@ -518,10 +518,7 @@ a look at the following resources: <dl> <dd> - <a href="https://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf">SEV API spec</a> - </dd> - <dd> - <a href="http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_E…">SEV White Paper</a> + <a href="https://developer.amd.com/sev/">SEV further reading</a> </dd> <dd> <a href="formatdomain.html#launchSecurity">SEV in domain XML</a> -- 2.20.1

2 2

[libvirt] [PATCH 0/2] tests: Add aarch64-gigabyte sysinfo test case
by Andrea Bolognani 30 May '19

30 May '19

This is intended to validate that using dmidecode on aarch64[1] works as expected. [1] https://www.redhat.com/archives/libvir-list/2019-May/msg00244.html Andrea Bolognani (2): tests: Tweak x86 sysinfo test case tests: Add aarch64-gigabyte sysinfo test case .../sysinfodata/aarch64-gigabytecpuinfo.data | 288 ++++++++ .../sysinfodata/aarch64-gigabytedmidecode.sh | 3 + .../sysinfodata/aarch64-gigabytesysinfo.data | 619 ++++++++++++++++++ .../aarch64-gigabytesysinfo.expect | 1 + .../{dmidecode.sh => x86dmidecode.sh} | 0 tests/sysinfotest.c | 4 +- 6 files changed, 914 insertions(+), 1 deletion(-) create mode 100644 tests/sysinfodata/aarch64-gigabytecpuinfo.data create mode 100755 tests/sysinfodata/aarch64-gigabytedmidecode.sh create mode 100644 tests/sysinfodata/aarch64-gigabytesysinfo.data create mode 100644 tests/sysinfodata/aarch64-gigabytesysinfo.expect rename tests/sysinfodata/{dmidecode.sh => x86dmidecode.sh} (100%) -- 2.21.0

2 3

[libvirt] [PATCH 0/9] util/resctrl cleanups and refactors
by Wang Huaqiang 30 May '19

30 May '19

Plan to support Resctrl Control Monitors, which is a feature introduced by kernel 'resctrl' sub-model. Submit some cleanup and refactoring patches for upcoming memory bandwidth resource monitoring (MBM) monitors. Related MBM RFC is https://www.redhat.com/archives/libvir-list/2019-April/msg01409.html. This RFC is not actively discussed since libvirt already implemented similar resctrl cache monitoring (CMT), and lots details have been discussed and implemented during the work of CMT. The cleanups and refactoring includes: 1. Removing some reluctant lines and white spaces that is existing in current code and not meet the libvirt coding style. 2. Replace 'virResctrlAllocIsEmpty' with @n==0 for indicating no resctrl allocation in configuration file. 3. Private API changes, removed 'virResctrlMonitorGetCacheOccupancy' and exported a new API named 'virResctrlMonitorGetStats' with similar functionality, but with capability to be used for retrieving MBM statistical information. 4. Refactoring 'virResctrlMonitorFreeStats' for more reusing in code. 5. Extend data structure 'virResctrlMonitorStats' with the capability to carry multiple statistical information from monitor. Wang Huaqiang (9): conf: code cleanup, remove empty line and one space conf: code cleanup for return error code directly conf: check if vcpus matches with any 'existing' allocaiton conf: Replace 'virResctrlAllocIsEmpty' with @n==0 for indicating no resctrl allocation in configuration file conf: refactor 'virDomainResctrlVcpuMatch' util: Refactor 'virResctrlMonitorFreeStats' util: Refactor 'virResctrlMonitorStats' util: Extend virresctl API to retrieve multiple monitor statistics util: Remove unused virResctrlMonitorGetCacheOccupancy src/conf/domain_conf.c | 89 +++++++++++++++++++++++------------------------- src/libvirt_private.syms | 2 +- src/qemu/qemu_driver.c | 36 +++++++++++++++----- src/util/virresctrl.c | 68 +++++++++++++++--------------------- src/util/virresctrl.h | 19 ++++++++--- 5 files changed, 113 insertions(+), 101 deletions(-) -- 2.7.4

3 25

[libvirt] [PATCH v2 0/2] virSysinfo: Try dmidecode on aarch64
by Michal Privoznik 30 May '19

30 May '19

v2 of: https://www.redhat.com/archives/libvir-list/2019-May/msg00221.html diff to v1: - Pushed 1/3 and 2/3 from v1 as they were ACKed already - New patch 1/2 which renames virSysinfoReadX86 - Patch 2/2 then uses the renamed function Michal Prívozník (2): virsysinfo: Rename virSysinfoReadX86 to virSysinfoReadDMI virSysinfoReadARM: Try reading DMI table src/libvirt_private.syms | 2 +- src/util/virsysinfo.c | 22 ++++++++++++++++++++-- src/util/virsysinfopriv.h | 2 +- tests/sysinfotest.c | 2 +- 4 files changed, 23 insertions(+), 5 deletions(-) -- 2.21.0

3 5

[libvirt] [PATCH v2] qemu: aquire job in qemuDomainDefineXMLFlags
by Nikolay Shirokovskiy 30 May '19

30 May '19

The function updates vm->newDef and frees previous pesistent definition which can be used by in different thread by some API that unlocks domain to communicate to qemu. So we have an access to freed memory in that thread. Let's acquire job condition in case of updating exiting domain. Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy(a)virtuozzo.com> --- diff from v1 [1]: - pay a bit of attention to the problem Reproducer in the Michal's reply to the [1]. [1] https://www.redhat.com/archives/libvir-list/2019-May/msg00804.html src/qemu/qemu_driver.c | 37 +++++++++++++++++++++++++++++++++++-- 1 file changed, 35 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 42b1ce2..2dd4442 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -7620,6 +7620,7 @@ qemuDomainDefineXMLFlags(virConnectPtr conn, virDomainDefPtr def = NULL; virDomainDefPtr oldDef = NULL; virDomainObjPtr vm = NULL; + virDomainObjPtr exvm = NULL; virDomainPtr dom = NULL; virObjectEventPtr event = NULL; virQEMUDriverConfigPtr cfg; @@ -7647,10 +7648,34 @@ qemuDomainDefineXMLFlags(virConnectPtr conn, if (virDomainDefineXMLFlagsEnsureACL(conn, def) < 0) goto cleanup; + if ((exvm = virDomainObjListFindByUUID(driver->domains, def->uuid))) { + if (qemuDomainObjBeginJob(driver, exvm, QEMU_JOB_MODIFY) < 0) { + virDomainObjEndAPI(&exvm); + goto cleanup; + } + virObjectUnlock(exvm); + } + if (!(vm = virDomainObjListAdd(driver->domains, def, driver->xmlopt, - 0, &oldDef))) + 0, &oldDef))) { + if (exvm) + virObjectLock(exvm); goto cleanup; + } + + if (exvm) { + if (vm != exvm) { + virReportError(VIR_ERR_OPERATION_FAILED, + _("domain '%s' is removed"), def->name); + virObjectLock(exvm); + goto cleanup; + } + + /* we don't need extra reference for same domain */ + virObjectUnref(exvm); + } + def = NULL; vm->persistent = 1; @@ -7670,7 +7695,10 @@ qemuDomainDefineXMLFlags(virConnectPtr conn, /* Brand new domain. Remove it */ VIR_INFO("Deleting domain '%s'", vm->def->name); vm->persistent = 0; - qemuDomainRemoveInactiveJob(driver, vm); + if (exvm) + qemuDomainRemoveInactive(driver, vm); + else + qemuDomainRemoveInactiveJob(driver, vm); } goto cleanup; } @@ -7685,8 +7713,13 @@ qemuDomainDefineXMLFlags(virConnectPtr conn, dom = virGetDomain(conn, vm->def->name, vm->def->uuid, vm->def->id); cleanup: + if (exvm) + qemuDomainObjEndJob(driver, exvm); + virDomainDefFree(oldDef); virDomainDefFree(def); + if (exvm && exvm != vm) + virDomainObjEndAPI(&exvm); virDomainObjEndAPI(&vm); virObjectEventStateQueue(driver->domainEventState, event); virObjectUnref(caps); -- 1.8.3.1

2 1

[libvirt] [PATCH v2 0/2] introduction of version attribute for VFIO live migration
by Yan Zhao 29 May '19

29 May '19

This patchset introduces a version attribute under sysfs of VFIO Mediated devices. This version attribute is used to check whether two mdev devices are compatible. user space software can take advantage of this version attribute to determine whether to launch live migration between two mdev devices. Patch 1 defines version attribute in Documentation/vfio-mediated-device.txt Patch 2 uses GVT as an example to show how to expose version attribute and check device compatibility in vendor driver. v2: 1. renamed patched 1 2. made definition of device version string completely private to vendor driver 3. abandoned changes to sample mdev drivers 4. described intent and usage of version attribute more clearly. Yan Zhao (2): vfio/mdev: add version attribute for mdev device drm/i915/gvt: export mdev device version to sysfs for Intel vGPU Documentation/vfio-mediated-device.txt | 135 ++++++++++++++++++++++ drivers/gpu/drm/i915/gvt/Makefile | 2 +- drivers/gpu/drm/i915/gvt/device_version.c | 84 ++++++++++++++ drivers/gpu/drm/i915/gvt/gvt.c | 51 ++++++++ drivers/gpu/drm/i915/gvt/gvt.h | 6 + 5 files changed, 277 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/i915/gvt/device_version.c -- 2.17.1

7 45