July 2019 - Devel - libvirt List Archives

[libvirt] [PATCH RFC 00/11] qemu: Introduce support for ARM CPU features
by Andrea Bolognani 07 Nov '19

07 Nov '19

This series is RFC because the corresponding QEMU patches[1] have not been merged yet, and since QEMU is currently in the middle of the 4.1.0 freeze we can't really expect to merge them until 5.7.0 anyway. With that in mind, a few patches are somewhat independent of the rest and could, after some minor tweaking, could go in even right now: 1/11 is really a no brainer, and 3/11 - 5/11 are also fairly reasonable candidates for that treatment. [1] https://lists.nongnu.org/archive/html/qemu-devel/2019-06/msg04945.html Andrea Bolognani (11): tests: Update replies for QEMU 2.12.0 on aarch64 tests: Add replies for QEMU 4.1.0 on aarch64 qemu: Rename virQEMUCapsObjectPropsMaxX86CPU qemu: Introduce QEMU_CAPS_ARM_MAX_CPU qemu: Query max-arm-cpu properties qemu: Update query-cpu-model-expansion check qemu: Perform full expansion on ARM cpu_map: Introduce ARM CPU features cpu: Validate ARM CPU features tests: Introduce tests for ARM CPU features news: Update for ARM CPU features docs/news.xml | 9 + src/cpu/cpu_arm.c | 171 ++ src/cpu_map/arm_features.xml | 21 + src/cpu_map/index.xml | 4 + src/qemu/qemu_capabilities.c | 18 +- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 3 +- .../caps_2.12.0.aarch64.replies | 324 ++- .../caps_2.12.0.aarch64.xml | 5 +- .../caps_4.0.0.aarch64.replies | 159 +- .../caps_4.0.0.aarch64.xml | 1 + ...h64.replies => caps_4.1.0.aarch64.replies} | 2205 ++++++++++------- ...0.0.aarch64.xml => caps_4.1.0.aarch64.xml} | 53 +- .../aarch64-features-sve.aarch64-latest.args | 32 + .../qemuxml2argvdata/aarch64-features-sve.xml | 20 + .../aarch64-features-wrong.xml | 17 + tests/qemuxml2argvtest.c | 7 + 17 files changed, 2085 insertions(+), 965 deletions(-) create mode 100644 src/cpu_map/arm_features.xml copy tests/qemucapabilitiesdata/{caps_4.0.0.aarch64.replies => caps_4.1.0.aarch64.replies} (96%) copy tests/qemucapabilitiesdata/{caps_4.0.0.aarch64.xml => caps_4.1.0.aarch64.xml} (80%) create mode 100644 tests/qemuxml2argvdata/aarch64-features-sve.aarch64-latest.args create mode 100644 tests/qemuxml2argvdata/aarch64-features-sve.xml create mode 100644 tests/qemuxml2argvdata/aarch64-features-wrong.xml -- 2.21.0

2 15

[libvirt] [PATCH 0/3] Fix ppc64 CPU configuration for QEMU 2.11+
by Jiri Denemark 08 Oct '19

08 Oct '19

The original fix was both incomplete and too general. It only fixed domain startup, but libvirt would still report empty list of supported CPU models with recent QEMU for ppc64. On the other hand, while ppc64 QEMU ignores case when looking up CPU model names, x86_64 QEMU does case sensitive lookup. Jiri Denemark (3): Revert "domcaps: Treat host models as case-insensitive strings" util: Introduce virStringListSearch qemu: Adapt to changed ppc64 CPU model names src/conf/domain_capabilities.c | 2 +- src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 28 +++++++++++++++++-- src/qemu/qemu_capabilities.h | 3 +- src/qemu/qemu_process.c | 2 +- src/util/virstring.c | 28 +++++++++++++++++++ src/util/virstring.h | 3 ++ .../qemu_2.12.0.ppc64.xml | 6 +++- .../caps_2.12.0.ppc64.xml | 12 ++++---- 9 files changed, 73 insertions(+), 12 deletions(-) -- 2.17.0

2 7

[libvirt] [PATCH] libvirt.spec.in: Add the Secure Boot-variant OVMF binaries
by Kashyap Chamarthy 11 Sep '19

11 Sep '19

Currently the RPM spec doesn't add the 'secboot'-variant OVMF binaries (an unintentional omission, checking with Cole on #virt, OFTC) for 'x86_64' and 'ia32'. Add them. This way, getDomainCapabilities() will report all the OVMF binaries that are present on the system. E.g. on Fedora 29, if you only have the edk2-ovmf-20190308stable-1.fc29.noarch package installed, then running `virsh domcapabilities` will enumerate _both_ the OVMF binaries (instead of just the OVMF_CODE.fd): $> virsh getdomcapabilities ... <loader supported='yes'> <value>/usr/share/edk2/ovmf/OVMF_CODE.fd</value> <value>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</value> ... ( Learnt this from a discussion with Michal Privoznik in this bug, comment#2: https://bugzilla.redhat.com/show_bug.cgi?id=1733940 -- RFE: Report firmware (FW) paths in domainCapabilities based on FW descriptor files ) Signed-off-by: Kashyap Chamarthy <kchamart(a)redhat.com> --- I only did a cursory check on if I missed to add any other valid paths for other architectures. --- libvirt.spec.in | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index b13b863928..99950495a7 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1135,10 +1135,17 @@ exit 1 # Nightly edk2.git-arm LOADERS="$LOADERS:/usr/share/edk2.git/arm/QEMU_EFI-pflash.raw:/usr/share/edk2.git/arm/vars-template-pflash.raw" - # Fedora edk2-ovmf + # Fedora edk2-ovmf, x86_64 LOADERS="$LOADERS:/usr/share/edk2/ovmf/OVMF_CODE.fd:/usr/share/edk2/ovmf/OVMF_VARS.fd" + # Fedora edk2-ovmf, x86_64, with Secure Boot + LOADERS="$LOADERS:/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd:/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd" # Fedora edk2-ovmf-ia32 LOADERS="$LOADERS:/usr/share/edk2/ovmf-ia32/OVMF_CODE.fd:/usr/share/edk2/ovmf-ia32/OVMF_VARS.fd" + # Fedora edk2-ovmf-ia32, with Secure Boot. (NB: Unlike x86_64, for + # 'ia32', there is no secboot-variant "VARS" file (NVRAM template). + # So the NVRAM template for 'ovmf-ia32/OVMF_CODE.secboot.fd' is the + # same as the one for the non-secboot variant.) + LOADERS="$LOADERS:/usr/share/edk2/ovmf-ia32/OVMF_CODE.secboot.fd:/usr/share/edk2/ovmf-ia32/OVMF_VARS.fd" # Fedora edk2-aarch64 LOADERS="$LOADERS:/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw:/usr/share/edk2/aarch64/vars-template-pflash.raw" # Fedora edk2-arm -- 2.20.1

3 2

[libvirt] [PATCH v4 0/8] CPU Model Baseline and Comparison for s390x
by Collin Walling 10 Sep '19

10 Sep '19

Changelog: v3 - rebased on master v2 - numerous cleanups - removed "policy fix function" and now properly check for policy == -1 in the CPUDef -> JSON parser - resolved some memory leaks - added string arg to qemuMonitorJSONParseCPUModelData for error message to print out proper command name v1 - introduce baseline - split patches into small chunks - free'd lingering qemuMonitorCPUModelInfo pointer - when converting from virCPUDef -> virJSON, consider feature policy FORCED for enabled ___ To run these patches, execute the virsh hypervisor-cpu-compare or hypervisor-cpu-baseline commands and pass an XML file describing one or more CPU definition. You can use the definition from virsh domcapabilities or from a guest XML. There is no need extract it from the file and place it a new one, as the XML parser will look specifically for the CPU tags. ___ These patches hookup the virsh hypervisor-cpu-compare/baseline commands for the s390x architecture. They take an XML file describing some CPU definitions and passes the data to QEMU, where the actual CPU model comparison / baseline calculation is handled (available since QEMU 2.8.5). These calculations are compared against / baselined with the hypervisor CPU model, which can be observed via the virsh domcapabilities command for s390x. When baselining CPU models and the user appends the --features argument to the command, s390x will only report back features that supersede the base model definition. *NOTE* if the --features flag is intended to expand /ALL/ features available to a CPU model (such as the huge list of features reported by a full CPU model expansion), please let me know and I can resolve this. The first patch pulls some code out of the CPU Model Expansion JSON function so that it can be later used for the Comparison and Baseline JSON functions. The rest of the patches follow this sequence: - introduce JSON monitor functions - introduce capability and update test files - hook up monitor functions to virsh command Patch 7 pulls out some code from the CPUDef XML parser to be reused in the comparison hookup. Thanks. x86 and Power review by Daniel Henrique Barboza (thanks!) Collin Walling (8): qemu_monitor: helper functions for CPU models qemu_monitor: implement query-cpu-model-baseline qemu_capabilities: introduce QEMU_CAPS_QUERY_CPU_MODEL_BASELINE qemu_driver: hook up query-cpu-model-baseline qemu_monitor: implement query-cpu-model-comparison qemu_capabilities: introduce QEMU_CAPS_QUERY_CPU_MODEL_COMPARISON cpu_conf: xml to cpu definition parse helper qemu_driver: hook up query-cpu-model-comparison src/conf/cpu_conf.c | 30 +++ src/conf/cpu_conf.h | 6 + src/cpu/cpu.c | 14 +- src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 136 +++++++++++ src/qemu/qemu_capabilities.h | 18 ++ src/qemu/qemu_driver.c | 38 +++ src/qemu/qemu_monitor.c | 44 ++++ src/qemu/qemu_monitor.h | 18 ++ src/qemu/qemu_monitor_json.c | 297 ++++++++++++++++++++--- src/qemu/qemu_monitor_json.h | 20 ++ tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_3.0.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_4.0.0.s390x.xml | 2 + 18 files changed, 587 insertions(+), 49 deletions(-) -- 2.7.4

4 35

[libvirt] [PATCH v3 00/48] Split the libvirtd daemon into per-driver daemons
by Daniel P. Berrangé 27 Aug '19

27 Aug '19

This is what all the driver refactoring I've done has been about enabling. We gain new daemons for each driver, for the primary virt drivers: virtlibxld virtlxcd virtqemud virtvboxd virtvzd And again for the secondary drivers virtinterfaced virtnetworkd virtnodedevd virtnwfilterd virtsecretd virtstoraged Finally to support IP connectivity, and also the legacy lbivirtd UNIX domain socket (for the old libvirt remote driver SSH tunnelling): virtproxyd The the sake of facilitating upgrades, the existing libvirtd still exists and works the same way it always has. You either run libvirtd, or you run the per-driver daemons, never both. The remote driver will look to see whether libvirtd is running to figure out whether to connect to libvirtd or the new per-driver daemons. When auto-spawning daemons for nonroot users, we default to spawning the per-driver daemons. This can be controlled with a UR parameter "?mode=direct|legacy|auto", where 'direct' means per-driver and 'legacy' means libvirtd (or indirect via virtproxyd if that's running). Changed in v3: - Add identity forwarding between daemons for polkit auth - Make virtxend sockets conditional on Xen kernel - Other misc review fixes Changed in v2: - Added systemd unit files for service & sockets, ensuring conflicts with libvirtd - Fixed proxy to actually handle probing of URIs (still not quite perfect) - Renamed virtlibxld to virtxend as "xen" is the user facing name of the URI - Lazy loading of secondary drivers, so connecting to virtqemud does't auto-spawn all secondary driver daemons, until a relevant API is actually invoked - Actually generated config files / augeas files per daemon - Abort daemon startup if driver fails to load - Many other fixes A few nice to have things, but not merge blocking - MAYBE make it possible to disable build of libvirtd, or of the per-driver daemons so downstream vendors can decide which to ship. Alternatively they can just not include the binary in the package file list ? - Tuning of the daemon defaults for worker threads to better suit the fact that we have per-driver daemons - More work on RPM packaging to allow install of per-driver daemosn without pulling in libvirtd too Daniel P. Berrangé (48): build: make augeas-gentest.pl write to stdout build: collapse rules adding augeas tests to CLEANFILES build: create all augeas test files in same dir as their source build: use a common rule for checking augeas test data files build: centralize rule for handling generated config files remote: stop trying to print help as giant blocks of text remote: conditionalize socket names in libvirtd daemon remote: conditionalize daemon name in libvirtd daemon remote: conditionalize driver loading in libvirtd daemon remote: conditionalize IP socket usage in libvirtd daemon build: use @CONFIG@ instead of ::CONFIG:: in augeas tests remote: conditionalize IP socket config in libvirtd.conf remote: conditionalize IP socket config in augeas definitions remote: refactor & rename variables for building libvirtd build: don't hardcode /etc in the config related files remote: reduce duplication in systemd unit file make rules into one remote: conditionalize systemd socket unit files remote: refactor how list of systemd unit files is built remote: in per-driver daemons ensure that state initialize succeeds remote: introduce virtproxyd daemon to handle IP connectivity secret: introduce virtsecretd daemon network: introduce virtnetworkd daemon interface: introduce virtinterfaced daemon storage: introduce virtstoraged daemon nodedev: introduce virtnodedevd daemon nwfilter: introduce virtnwfilterd daemon libxl: introduce virtxend daemon qemu: introduce virtqemud daemon lxc: introduce virtlxcd daemon vbox: introduce virtvboxd daemon bhyve: introduce virtbhyved daemon vz: introduce virtvzd daemon admin: add ability to connect to the per-driver daemon sockets remote: get rid of bogus ATTRIBUTE_UNUSED annotation client param remote: change generated methods to not directly access connection remote: fix lock ordering mistake in event registration remote: change hand written methods to not directly access connection remote: open secondary drivers via remote driver if needed remote: handle autoprobing of driver within virtproxyd remote: use enum helpers for parsing remote driver transport remote: refactor the code for choosing the UNIX socket path remote: enable connecting to the per-driver daemons api: introduce virConnectSetIdentity for pasing uid, gid, selinux info util: change identity class attribute names util: make generic identity accessors private util: storage identity attrs as virTypedParameter internally util: allow identity to be imported/exported as typed parameters remote: pass identity across to newly opened daemons .gitignore | 62 +- build-aux/augeas-gentest.pl | 22 +- docs/remote.html.in | 18 + include/libvirt/libvirt-host.h | 75 + libvirt.spec.in | 91 ++ m4/virt-driver-remote.m4 | 15 + src/Makefile.am | 30 +- src/access/viraccessdriverpolkit.c | 12 +- src/admin/admin_server.c | 10 +- src/admin/admin_server_dispatch.c | 9 + src/bhyve/Makefile.inc.am | 55 +- src/bhyve/bhyve_driver.c | 10 +- src/bhyve/test_libvirtd_bhyve.aug.in | 2 +- src/driver-hypervisor.h | 7 + src/driver-state.h | 8 +- src/driver.h | 2 + src/interface/Makefile.inc.am | 62 + src/interface/interface_backend_netcf.c | 8 +- src/interface/interface_backend_udev.c | 4 +- src/interface/virtinterfaced.service.in | 24 + src/libvirt-admin.c | 32 +- src/libvirt-host.c | 51 + src/libvirt.c | 42 +- src/libvirt_internal.h | 1 + src/libvirt_private.syms | 29 +- src/libvirt_public.syms | 1 + src/libvirt_remote.syms | 1 + src/libxl/Makefile.inc.am | 80 +- src/libxl/libxl_driver.c | 10 +- src/libxl/test_libvirtd_libxl.aug.in | 2 +- src/libxl/virtxend.service.in | 26 + src/locking/Makefile.inc.am | 77 +- src/locking/test_libvirt_lockd.aug.in | 2 +- src/locking/test_libvirt_sanlock.aug.in | 2 +- src/locking/test_virtlockd.aug.in | 2 +- src/locking/virtlockd.service.in | 2 +- src/logging/Makefile.inc.am | 23 +- src/logging/test_virtlogd.aug.in | 2 +- src/logging/virtlogd.service.in | 2 +- src/lxc/Makefile.inc.am | 77 +- src/lxc/lxc_driver.c | 12 +- src/lxc/test_libvirtd_lxc.aug.in | 2 +- src/lxc/virtlxcd.service.in | 40 + src/network/Makefile.inc.am | 61 + src/network/bridge_driver.c | 4 +- src/network/virtnetworkd.service.in | 25 + src/node_device/Makefile.inc.am | 62 + src/node_device/node_device_hal.c | 12 +- src/node_device/node_device_udev.c | 8 +- src/node_device/virtnodedevd.service.in | 24 + src/nwfilter/Makefile.inc.am | 62 + src/nwfilter/nwfilter_driver.c | 12 +- src/nwfilter/virtnwfilterd.service.in | 24 + src/qemu/Makefile.inc.am | 76 +- src/qemu/qemu_driver.c | 8 +- src/qemu/test_libvirtd_qemu.aug.in | 2 +- src/qemu/virtqemud.service.in | 40 + src/remote/Makefile.inc.am | 285 ++-- src/remote/libvirtd-admin.socket.in | 15 +- src/remote/libvirtd-ro.socket.in | 15 +- src/remote/libvirtd-tcp.socket.in | 13 +- src/remote/libvirtd-tls.socket.in | 13 +- src/remote/{libvirtd.aug => libvirtd.aug.in} | 26 +- .../{libvirtd.conf => libvirtd.conf.in} | 60 +- src/remote/libvirtd.service.in | 2 +- src/remote/libvirtd.socket.in | 11 +- src/remote/remote_daemon.c | 302 ++-- src/remote/remote_daemon.h | 13 + src/remote/remote_daemon_config.c | 47 +- src/remote/remote_daemon_config.h | 10 +- src/remote/remote_daemon_dispatch.c | 1354 ++++++++++------- src/remote/remote_driver.c | 424 ++++-- src/remote/remote_driver.h | 4 - src/remote/remote_protocol.x | 18 +- src/remote/test_libvirtd.aug.in | 24 +- src/remote/virtproxyd.service.in | 24 + src/remote_protocol-structs | 8 + src/rpc/gendispatch.pl | 96 +- src/rpc/virnetserverclient.c | 24 +- src/rpc/virnetserverclient.h | 2 + src/secret/Makefile.inc.am | 62 + src/secret/secret_driver.c | 8 +- src/secret/virtsecretd.service.in | 24 + src/storage/Makefile.inc.am | 61 + src/storage/storage_driver.c | 8 +- src/storage/virtstoraged.service.in | 26 + src/util/viridentity.c | 483 +++--- src/util/viridentity.h | 87 +- src/vbox/Makefile.inc.am | 62 + src/vbox/virtvboxd.service.in | 25 + src/vz/Makefile.inc.am | 62 + src/vz/virtvzd.service.in | 25 + src/vz/vz_driver.c | 14 +- tests/viridentitytest.c | 97 +- tests/virnetserverclienttest.c | 45 +- tools/libvirt-guests.service.in | 2 +- 96 files changed, 3642 insertions(+), 1703 deletions(-) create mode 100644 src/interface/virtinterfaced.service.in create mode 100644 src/libxl/virtxend.service.in create mode 100644 src/lxc/virtlxcd.service.in create mode 100644 src/network/virtnetworkd.service.in create mode 100644 src/node_device/virtnodedevd.service.in create mode 100644 src/nwfilter/virtnwfilterd.service.in create mode 100644 src/qemu/virtqemud.service.in rename src/remote/{libvirtd.aug => libvirtd.aug.in} (89%) rename src/remote/{libvirtd.conf => libvirtd.conf.in} (92%) create mode 100644 src/remote/virtproxyd.service.in create mode 100644 src/secret/virtsecretd.service.in create mode 100644 src/storage/virtstoraged.service.in create mode 100644 src/vbox/virtvboxd.service.in create mode 100644 src/vz/virtvzd.service.in -- 2.21.0

5 118

[libvirt] [PATCH 00/19] Add vhost-user-gpu support
by marcandre.lureau＠redhat.com 23 Aug '19

23 Aug '19

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Hi, This series of patches adds support for running virtio GPUs in seperate processes, thanks to vhost-user backend. The QEMU support landed for 4.1. There are several benefits of running the GPU/virgl in an external process, since Mesa is rather heavy on the qemu main loop, and may block for a while, or crash. The external GPU process is started with one end of a socket pair, the other end is given to a QEMU chardev attached to a device. The external process is also added to the cgroup to limit resources usage. Thanks Since RFC: - discover helpers following the vhost-user spec - change vhost-user <video> model for a vhostuser attribute - add a patch to specify the rendernode on <accel> - change the way command line is built, following qemu series changes - socket labeling - a few cleanup patches - rebased Marc-André Lureau (19): device-conf: removed unneeded virDomainDeviceInfoCopy() tpm: minor argument comment fix qemu_firmware: only set nfeatures on success qemu: extract out qemuFetchConfigs from firmware domain: add "vhostuser" attribute to virtio video model domain: add rendernode attribute on <accel> qemu-cgroup: allow accel rendernode access qemu: add vhost-user-gpu capabilities checks qemu: check that qemu is vhost-user-vga capable qemu: validate virtio-gpu with vhost-user qemu: restrict 'virgl=' option to non-vhostuser video type qemu: add vhost-user helpers qemu: add qemuSecurityStartVhostUserGPU helper qemu: add vhost-user-gpu helper unit qemu: prepare domain for vhost-user GPU qemu: start/stop the vhost-user-gpu external device qemu: build vhost-user GPU devices tests: mock execv/execve tests: add vhost-user-gpu xml2argv tests docs/formatdomain.html.in | 11 + docs/schemas/domaincommon.rng | 16 +- src/conf/device_conf.c | 22 +- src/conf/device_conf.h | 4 +- src/conf/domain_conf.c | 33 +- src/conf/domain_conf.h | 2 + src/libvirt_private.syms | 1 - src/qemu/Makefile.inc.am | 6 + src/qemu/qemu_capabilities.c | 6 + src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c | 24 ++ src/qemu/qemu_command.c | 54 ++- src/qemu/qemu_configs.c | 183 ++++++++ src/qemu/qemu_configs.h | 31 ++ src/qemu/qemu_domain.c | 10 +- src/qemu/qemu_extdevice.c | 79 +++- src/qemu/qemu_extdevice.h | 5 + src/qemu/qemu_firmware.c | 146 +------ src/qemu/qemu_process.c | 18 +- src/qemu/qemu_security.c | 48 +++ src/qemu/qemu_security.h | 6 + src/qemu/qemu_tpm.c | 2 +- src/qemu/qemu_vhost_user.c | 395 ++++++++++++++++++ src/qemu/qemu_vhost_user.h | 51 +++ src/qemu/qemu_vhost_user_gpu.c | 307 ++++++++++++++ src/qemu/qemu_vhost_user_gpu.h | 54 +++ tests/Makefile.am | 9 + .../etc/qemu/vhost-user/40-gpu.json | 1 + .../etc/qemu/vhost-user/50-gpu.json | 0 .../qemu/vhost-user/test-vhost-user-gpu | 11 + .../usr/share/qemu/vhost-user/30-gpu.json | 1 + .../usr/share/qemu/vhost-user/50-gpu.json | 8 + .../usr/share/qemu/vhost-user/60-gpu.json | 1 + tests/qemuvhostusertest.c | 132 ++++++ .../vhost-user-gpu-secondary.args | 35 ++ .../vhost-user-gpu-secondary.xml | 44 ++ tests/qemuxml2argvdata/vhost-user-vga.args | 32 ++ tests/qemuxml2argvdata/vhost-user-vga.xml | 41 ++ tests/qemuxml2argvtest.c | 21 + tests/virfilewrapper.c | 22 + 40 files changed, 1690 insertions(+), 186 deletions(-) create mode 100644 src/qemu/qemu_configs.c create mode 100644 src/qemu/qemu_configs.h create mode 100644 src/qemu/qemu_vhost_user.c create mode 100644 src/qemu/qemu_vhost_user.h create mode 100644 src/qemu/qemu_vhost_user_gpu.c create mode 100644 src/qemu/qemu_vhost_user_gpu.h create mode 120000 tests/qemuvhostuserdata/etc/qemu/vhost-user/40-gpu.json create mode 100644 tests/qemuvhostuserdata/etc/qemu/vhost-user/50-gpu.json create mode 100755 tests/qemuvhostuserdata/usr/libexec/qemu/vhost-user/test-vhost-user-gpu create mode 120000 tests/qemuvhostuserdata/usr/share/qemu/vhost-user/30-gpu.json create mode 100644 tests/qemuvhostuserdata/usr/share/qemu/vhost-user/50-gpu.json create mode 120000 tests/qemuvhostuserdata/usr/share/qemu/vhost-user/60-gpu.json create mode 100644 tests/qemuvhostusertest.c create mode 100644 tests/qemuxml2argvdata/vhost-user-gpu-secondary.args create mode 100644 tests/qemuxml2argvdata/vhost-user-gpu-secondary.xml create mode 100644 tests/qemuxml2argvdata/vhost-user-vga.args create mode 100644 tests/qemuxml2argvdata/vhost-user-vga.xml -- 2.22.0.rc2.384.g1a9a72ea1d

4 26

[libvirt] [PATCH v1 00/11] Couple of storage driver improvements
by Michal Privoznik 23 Aug '19

23 Aug '19

Patches 02/11, 09/11 and finally 11/11 are actual bug fixes. The rest is a preparation work. More detailed: 02/11 - Fixes a refcounting issue (and thus invalid memory access) 09/11 - Fixes a problem where starting a transitive pool which has a persistent config may lead to it's disappearance 11/11 - Tries to relax locking to allow more concurrent access Michal Prívozník (11): virStoragePoolObjRemove: Don't unlock pool object upon return virStoragePoolObjListForEach: Grab a reference for pool object storagePoolRefreshImpl: Fix variable name in comment virStoragePoolUpdateInactive: Don't call virStoragePoolObjEndAPI virstorageobj: Rename virStoragePoolObjAssignDef virStoragePoolObjListAdd: Turn boolean arg into flags virStoragePoolObjListAdd: Separate out definition assignment virstorageobj: Introduce VIR_STORAGE_POOL_OBJ_LIST_ADD_LIVE flag storagePoolCreateXML: Don't lose persistent storage on failed create storage_driver: Protect pool def during startup and build storage: Drop and reacquire pool obj lock in some backends src/conf/virstorageobj.c | 89 ++++++++++++++++++++------ src/conf/virstorageobj.h | 17 ++++- src/libvirt_private.syms | 4 +- src/storage/storage_backend_disk.c | 11 +++- src/storage/storage_backend_fs.c | 13 +++- src/storage/storage_backend_logical.c | 15 +++-- src/storage/storage_backend_vstorage.c | 9 ++- src/storage/storage_backend_zfs.c | 7 +- src/storage/storage_driver.c | 67 +++++++++++-------- src/test/test_driver.c | 21 ++---- 10 files changed, 181 insertions(+), 72 deletions(-) -- 2.21.0

3 25

[libvirt] RFC: revival of hotplug/unplug for PCI Multifunction devices in QEMU guests
by Daniel Henrique Barboza 23 Aug '19

23 Aug '19

Hi, This is labeled as RFC but it's more like a FYI to let people know and comment beforehand. Shiva sent a 28 patch series last year that implements hotplug/unplug support for PCI multifunction devices [1]. The design motivation of his work was based in a RFC sent to this mailing list back in 2016 [2]. I'll briefly summarize the goals and motivations here. What we have today in Libvirt: - no hotplug/unplug support for multifunction PCI devices This is explained in details in [2]. When hotplugging a multifunction device, QEMU will queue the hotplug operation of all non-zero functions and, when function 0 is hotplugged, all functions are hotplugged together. This is true for all archs that supports PCI multifunction devices in QEMU. For unplug it varies: x86 will unplug all functions if any function is unplugged, ppc64 needs to unplug each one. Due to the nature of how Libvirt hotplug works now, hotplug of these devices is not possible. All hotplugs are considered in an isolated manner. Even if we hotplug each function in the proper order (i.e. leaving function 0 last), Libvirt can assign different slots in the guest for each. Similar problems happens with hot-unplug. This feature aims to address these by creating a new <devices> element, exclusive for multifunction devices, that aggregates all functions of a device in a single operation. To handle this new element, the existing attach/detach functions in the QEMU driver now handles multiple devices. Attaching/detaching a single device is routed away from the specialized multifunction code to be handled to the existing attach/detach code base. - no support for partial assignment of functions We can't make the assumption that the guest will always assign all devices of a multifunction device. Some functions might be a security risk to expose to a guest, or the device can behave differently depending on the amount of functions assigned. Even if the 'leftover' functions can't be used to anything else in the host, the decision of full/partial assignment of functions should come from the user, not us. We can't predict how any other hardware vendor will setup its devices. This patch series also handles this case. ------ The latest version of this feature, rebase to cdd362e0e7a (the current master as I'm writing this), can be found at: https://github.com/danielhb/libvirt/tree/multifunction-rc2 This is a work still ongoing that it's not ready for contribution yet (first patches that changes the unit test code are breaking existing tests). The feature itself is being stress tested using a Broadcom BCM5719 with 4 functions and it looks solid. I'll see if I can grab a x86 env with a multifunction card to test it there too when I have the chance. Thoughts/comments are welcome. Instead of dropping a 28+ patch set for review, I'm planning into sending smaller chunks that makes senses individually. Thanks, DHB [1] https://www.redhat.com/archives/libvir-list/2018-March/msg00729.html [2] https://www.redhat.com/archives/libvir-list/2016-April/msg01057.html

3 7

[libvirt] [PATCH v2 0/9] More consistent virDomainUndefine flag handling
by Eric Blake 21 Aug '19

21 Aug '19

Since v1: - use syntax-check rather than dynamic runtime check for API mismatch - fix more stragglers with mismatched API, found by the syntax-check - fix a bug in bhyve no-op flag handling - expand no-op flag handling to other affected drivers Eric Blake (9): vbox: Add various vir*Flags API xenapi: Add various vir*Flags API maint: Enhance check-driverimpls.pl to check for API pairing bhyve: Ignore no-op flag during virDomainUndefine libxl: Ignore no-op flag during virDomainUndefine lxc: Ignore no-op flag during virDomainUndefine openvz: Ignore no-op flag during virDomainUndefine vmware: Ignore no-op flag during virDomainUndefine xenapi: Ignore no-op flag during virDomainUndefine src/bhyve/bhyve_driver.c | 6 +++++- src/check-driverimpls.pl | 33 +++++++++++++++++++++++++++++++-- src/libxl/libxl_driver.c | 4 +++- src/lxc/lxc_driver.c | 5 ++++- src/openvz/openvz_driver.c | 5 ++++- src/vbox/vbox_common.c | 24 ++++++++++++++++++++++-- src/vmware/vmware_driver.c | 5 ++++- src/xenapi/xenapi_driver.c | 28 ++++++++++++++++++++++++---- 8 files changed, 97 insertions(+), 13 deletions(-) -- 2.20.1

2 23

[libvirt] [PATCHv2 00/11] util/resctrl cleanups and refactors
by Wang Huaqiang 20 Aug '19

20 Aug '19

Patches submitted for purpose of refactoring existing 'resctrl' related source code, including some code cleanups as well as some fixes. This is also a preparation for memory bandwidth monitor codes. 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: v2 changes: 1. Addressed comments of v1. 2. Introduce a new algorithm for verifying new monitor vcpus and existing monitors and allocations. 3. Fixes for creating default-allocation-monitor in 'resctrl' file system.(patch 0001). v1 changes: 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 (11): util,conf: Handle default monitor group of an allocation properly conf: code cleanup, remove empty line and one space conf: code cleanup for return error code directly conf: some code cleanup conf: refactor 'virDomainResctrlVcpuMatch' and some code cleanup conf: Append 'resctrl' object according to number of monitor group directly util: Refactor and rename 'virResctrlMonitorFreeStats' util: Refactor 'virResctrlMonitorStats' util: Extend virresctl API to retrieve multiple monitor statistics util: Remove unused virResctrlMonitorGetCacheOccupancy conf: Refactor and rename the function to validate a new resctrl monitor src/conf/domain_conf.c | 145 ++++++++++++++++++++++++----------------------- src/libvirt_private.syms | 5 +- src/qemu/qemu_driver.c | 41 ++++++++++---- src/qemu/qemu_process.c | 3 +- src/util/virresctrl.c | 75 ++++++++++-------------- src/util/virresctrl.h | 23 +++++--- 6 files changed, 156 insertions(+), 136 deletions(-) -- 2.7.4

5 19