August 2019 - Devel - libvirt List Archives

[libvirt] [PATCH 0/7] util: abort when out of memory
by Daniel P. Berrangé 12 Sep '19

12 Sep '19

See this previous thread: https://www.redhat.com/archives/libvir-list/2019-May/msg00273.html The executive summary is that catching & reporting ENOMEM is not worth the maint cost because: - this code will almost never run on Linux hosts - if it does run it will likely have bad behaviour silently dropping data or crashing the process - apps using libvirt often do so via a non-C language that aborts/exits the app on OOM regardless, or use other C libraries that abort - we can build a system that is more reliable when OOM happens by not catching OOM, instead simply letting apps exit, restart and carry on where they left off The first part of the series does the bare minimum to cull OOM handling. With this done, the main reason why we never adopted glib is now removed. Thus the second part of this series introduces use of glib into libvirt and converts our our allocation APIs to use the glib allocation APIs internally. In future I'd especially like to use glib to replace virObject code, which I knowingly wrote as a somewhat pathetic clone of GObject. Eliminating all our DBus code is also another thing I'd like, since Glib's DBus client code is better IMHO. Note that none of the callers are updated at this point, so they are all still attempting to handle errors from VIR_ALLOC, VIR_STRDUP, etc. If we convert VIR_ALLOC calls to remove return value checks, and then later convert to glib's g_new0 API, we go through two lots of churn which I think is undesirable. Thus I think it is highly desirable to introduce glib straight away and do a single conversion step. It also means we can introduce other data structures from glib to replace ours and avoid wasting time converting those too. Overall the code in this series is all quite simple and a nice cleanup. 50% of the lines culled come from the first patch removing OOM testing, the other 50% come from viralloc.c impl simplification The interesting question is the impact is has on downstreams who have to backport patches to older versions. If we start converting callers to g_new0, etc, then downstream have to either * Change g_new0 back into VIR_ALLOC and likely re-add many goto calls we purged Or * Backport all the patches in this series that drop OOM handling and introduce glib usage If we start adopting other glib features beyond g_new0, then downstreams are pretty much forced into option 2. Given the benefit I think we'll see from this series in our codebase, I'm inclined to say we should prioritize the future, over prioritizing the past (backports), and thus freely adopt use of glib APIs rightaway. IOW, I think we should expect vendors to backport this series as a starting point, before any other patches. I've not tested but I'm hopeful that such a backport of this series is fairly easy. The viralloc.{c,h} file hasn't seen much change in recent times so ought to be a clean cherry-pick. The glib additions might hit some conflicts in makefiles, but not too terrible I hope. Probably worth doing a test to see just how easy backports are over the past 1 year of releases. Daniel P. Berrangé (7): util: purge all code for testing OOM handling util: make allocation functions abort on OOM util: remove several unused _QUIET allocation macro variants util: make string functions abort on OOM build: probe for glib-2 library in configure build: link to glib library util: use glib allocation functions configure.ac | 19 +- docs/docs.html.in | 3 - docs/internals/oomtesting.html.in | 213 -------------------- libvirt.spec.in | 1 + m4/virt-glib.m4 | 30 +++ mingw-libvirt.spec.in | 2 + src/Makefile.am | 2 + src/internal.h | 1 + src/libvirt_private.syms | 4 - src/lxc/Makefile.inc.am | 2 + src/remote/Makefile.inc.am | 1 + src/util/Makefile.inc.am | 1 + src/util/viralloc.c | 313 ++++-------------------------- src/util/viralloc.h | 204 ++++--------------- src/util/virstring.c | 93 +++------ src/util/virstring.h | 79 +++----- tests/Makefile.am | 4 +- tests/oomtrace.pl | 41 ---- tests/qemuxml2argvtest.c | 12 +- tests/testutils.c | 189 +----------------- tests/testutils.h | 2 - tests/virfirewalltest.c | 12 -- tools/Makefile.am | 1 + 23 files changed, 179 insertions(+), 1050 deletions(-) delete mode 100644 docs/internals/oomtesting.html.in create mode 100644 m4/virt-glib.m4 delete mode 100755 tests/oomtrace.pl -- 2.21.0

4 21

[libvirt] [PATCH v2 00/10] Adding resolution properties for video models
by jcfaracco＠gmail.com 11 Sep '19

11 Sep '19

From: Julio Faracco <jcfaracco(a)gmail.com> This serie adds 'xres' and 'yres' QEMU display properties into a new element called 'resolution'. This element is covered by model element: <model type='foo'> <resolution x='800' y='600'/> </model> Only types VGA, QXL, Virtio and Bochs support passing resolution to driver. That's why some test cases were added too. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1485793 Julio Faracco (10): docs: Adding 'xres' and 'yres' into qxl XML definition qemu: Include {xres,yres} QEMU capabilities for video models conf: Adding resolution property for model element qemu: Include {xres,yres} for QEMU command line tests: Include {xres,yres} QEMU capabilities into tests tests: Include bochs-display as capability test too tests: Introduce resolution test for QXL model tests: Introduce resolution test for Virtio model tests: Introduce resolution test for Bochs model tests: Introduce resolution test for VGA model docs/schemas/domaincommon.rng | 10 ++ src/conf/domain_conf.c | 75 +++++++- src/conf/domain_conf.h | 5 + src/conf/virconftypes.h | 3 + src/qemu/qemu_capabilities.c | 16 ++ src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 20 +++ .../caps_2.10.0.aarch64.xml | 2 + .../caps_2.10.0.ppc64.xml | 2 + .../caps_2.10.0.s390x.xml | 2 + .../caps_2.10.0.x86_64.xml | 2 + .../caps_2.11.0.s390x.xml | 2 + .../caps_2.11.0.x86_64.xml | 2 + .../caps_2.12.0.aarch64.xml | 2 + .../caps_2.12.0.ppc64.xml | 2 + .../caps_2.12.0.s390x.xml | 2 + .../caps_2.12.0.x86_64.xml | 2 + .../caps_3.0.0.ppc64.replies | 139 +++++++++++---- .../qemucapabilitiesdata/caps_3.0.0.ppc64.xml | 2 + .../caps_3.0.0.riscv32.xml | 2 + .../caps_3.0.0.riscv64.xml | 2 + .../qemucapabilitiesdata/caps_3.0.0.s390x.xml | 2 + .../caps_3.0.0.x86_64.replies | 167 +++++++++++++----- .../caps_3.0.0.x86_64.xml | 2 + .../caps_3.1.0.ppc64.replies | 139 +++++++++++---- .../qemucapabilitiesdata/caps_3.1.0.ppc64.xml | 2 + .../caps_3.1.0.x86_64.replies | 167 +++++++++++++----- .../caps_3.1.0.x86_64.xml | 2 + .../caps_4.0.0.aarch64.replies | 139 +++++++++++---- .../caps_4.0.0.aarch64.xml | 2 + .../caps_4.0.0.ppc64.replies | 139 +++++++++++---- .../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 2 + .../caps_4.0.0.riscv32.replies | 131 +++++++++++--- .../caps_4.0.0.riscv32.xml | 2 + .../caps_4.0.0.riscv64.replies | 131 +++++++++++--- .../caps_4.0.0.riscv64.xml | 2 + .../qemucapabilitiesdata/caps_4.0.0.s390x.xml | 2 + .../caps_4.0.0.x86_64.replies | 167 +++++++++++++----- .../caps_4.0.0.x86_64.xml | 2 + .../caps_4.1.0.x86_64.replies | 159 ++++++++++++----- .../caps_4.1.0.x86_64.xml | 2 + ...ochs-display-resolution.x86_64-latest.args | 35 ++++ .../video-bochs-display-resolution.xml | 33 ++++ .../video-qxl-resolution.x86_64-latest.args | 35 ++++ .../qemuxml2argvdata/video-qxl-resolution.xml | 33 ++++ ...o-virtio-gpu-resolution.x86_64-latest.args | 35 ++++ .../video-virtio-gpu-resolution.xml | 33 ++++ tests/qemuxml2argvtest.c | 4 + ...bochs-display-resolution.x86_64-latest.xml | 33 ++++ .../video-qxl-resolution.x86_64-latest.xml | 33 ++++ ...eo-virtio-gpu-resolution.x86_64-latest.xml | 33 ++++ tests/qemuxml2xmltest.c | 5 + 52 files changed, 1604 insertions(+), 365 deletions(-) create mode 100644 tests/qemuxml2argvdata/video-bochs-display-resolution.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/video-bochs-display-resolution.xml create mode 100644 tests/qemuxml2argvdata/video-qxl-resolution.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/video-qxl-resolution.xml create mode 100644 tests/qemuxml2argvdata/video-virtio-gpu-resolution.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/video-virtio-gpu-resolution.xml create mode 100644 tests/qemuxml2xmloutdata/video-bochs-display-resolution.x86_64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/video-qxl-resolution.x86_64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/video-virtio-gpu-resolution.x86_64-latest.xml -- 2.20.1

3 13

[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] domain_conf: Drop ancient reservation of unit 7 in drive address
by Michal Privoznik 11 Sep '19

11 Sep '19

Introduced in v1.0.6~3, the idea was that unit 7 was reserved and couldn't be used by QEMU. Well, that limitation is long gone. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/conf/domain_conf.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index b7a342bb91..6a019490fd 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -4812,12 +4812,6 @@ bool virDomainSCSIDriveAddressIsUsed(const virDomainDef *def, const virDomainDeviceDriveAddress *addr) { - /* In current implementation, the maximum unit number of a controller - * is either 16 or 7 (narrow SCSI bus), and if the maximum unit number - * is 16, the controller itself is on unit 7 */ - if (addr->unit == 7) - return true; - if (virDomainDriveAddressIsUsedByDisk(def, VIR_DOMAIN_DISK_BUS_SCSI, addr) || virDomainDriveAddressIsUsedByHostdev(def, -- 2.21.0

3 4

[libvirt] [PATCH v4 0/2] snapshot: Store both config and live XML in the
by Maxiwell S. Garcia 11 Sep '19

11 Sep '19

This patchset store both config and live XML in the snapshot XML. To avoid nest 'config' XML one level deeper ('inactive/domain'), it was necessary to create a function that has a new rootname parameter. V4: - Create a new function to format the XML domain choosing the root name Maxiwell S. Garcia (2): qemu: formatting XML from domain def choosing the root name snapshot: Store both config and live XML in the snapshot domain src/conf/domain_conf.c | 35 ++++++++++++++++++++++++++--------- src/conf/domain_conf.h | 6 ++++++ src/conf/moment_conf.c | 1 + src/conf/moment_conf.h | 11 +++++++++++ src/conf/snapshot_conf.c | 22 ++++++++++++++++++++-- src/qemu/qemu_driver.c | 37 ++++++++++++++++++++++++++++--------- 6 files changed, 92 insertions(+), 20 deletions(-) -- 2.20.1

3 8

[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 0/7] qemu_command: clean up more labels (virtio-fs epopee)
by Ján Tomko 10 Sep '19

10 Sep '19

Ján Tomko (7): qemuBuildHostNetStr: remove unused cfg qemuBuildHostNetStr: remove unused 'driver' argument qemuBuildHostNetStr: remove unnecessary cleanup label qemuBuildSoundCommandLine: reduce scope of codecstr qemuBuildMemoryBackendProps: remove useless cleanup label qemuBuildMemoryBackendProps: use 'rc' instead of ret. qemuBuildMemoryCellBackendStr: remove useless ret variable src/qemu/qemu_command.c | 87 ++++++++++++++++++----------------------- src/qemu/qemu_command.h | 1 - src/qemu/qemu_hotplug.c | 2 +- 3 files changed, 38 insertions(+), 52 deletions(-) -- 2.19.2

2 8

[libvirt] Error when creating VM with persistent memory
by Seema Pandit 10 Sep '19

10 Sep '19

I am trying to create a VM with added persistent memory using virsh. It fails when persistent memory namespace size is larger than available system memory. Please see error below, prealloc=yes is set in the command line. For dax type namespace, as I understand, prealloc should not be needed. Is this support to add persistent memory implemented in virsh? If so, how to set prealloc=no? Anything else needed to add in xml for persistent memory? Thanks. 1. dax namespace (400GB) which is larger than system memory. # ndctl create-namespace -t pmem -m devdax --align=4k -s 400G { "dev":"namespace1.0", "mode":"devdax", "map":"dev", "size":"393.75 GiB (422.78 GB)", "uuid":"00670b70-7871-4749-a901-9184b7a388d8", "raw_uuid":"a5a1d3f8-01e4-45a2-bad1-38fd09bf4672", "daxregion":{ "id":1, "size":"393.75 GiB (422.78 GB)", "align":4096, "devices":[ { "chardev":"dax1.0", "size":"393.75 GiB (422.78 GB)" } ] }, "numa_node":1 } 2. Relevant parts of xml <domain type='kvm'> <name>test</name> <uuid>02c49a19-ce9e-4320-9a6b-1ebf0913a10e</uuid> <maxMemory slots='16' unit='KiB'>459800576</maxMemory> <memory unit='KiB'>65536000</memory> <currentMemory unit='KiB'>65536000</currentMemory> <vcpu placement='static'>4</vcpu> <os> : : <cpu mode='custom' match='exact' check='partial'> <feature policy='require' name='hypervisor'/> <numa> <cell id='0' cpus='0-3' memory='65536000' unit='KiB'/> </numa> </cpu> : : <memory model='nvdimm'> <source> <path>/dev/dax1.0</path> </source> <target> <size unit='GiB'>376</size> <node>0</node> <label> <size unit='KiB'>128</size> </label> </target> <address type='dimm' slot='0'/> </memory> 3. Error: # virsh start test error: Failed to start domain test error: internal error: qemu unexpectedly closed the monitor: ftruncate: Invalid argument 2019-08-22T04:16:08.744402Z qemu-system-x86_64: -object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/dev/dax1.0,size=403726925824: unable to map backing store for guest RAM: Cannot allocate memory Virsh version 4.7.0, qemu version 3.0.0

4 8

[libvirt] [PATCH v3 0/5] PCI Multifunction hotplug/unplug, part 1
by Daniel Henrique Barboza 09 Sep '19

09 Sep '19

changes in v3: - rebased after all PCI test changes went to master. - a couple of patches were dropped due to redundancy with what Michal already pushed upstream. - patches 3 and 5 were already R-b by Michal in v2. Hi, In this new version I'm sending what was left to fix after Michal pushed his "Drop KVM assignment" series, which ended up having redundancy of fixes with the previous version. This is the first part of the feature discussed at [1]. These patches are mostly cleanup and fixes, thus it is beneficial to have them upstream right away. The whole feature can be checked out at [2]. All patches survives unit testing. The feature was stress tested with hundreds of consecutive hotplug/unplugs of a Broadcom BCM5719 multifunction network card in a guest running in a Power 8 server. Hopefully I'll find a suitable x86 env to stress test the feature there too. [1] https://www.redhat.com/archives/libvir-list/2019-June/msg00703.html [2] https://github.com/danielhb/libvirt/tree/multifunction_latest Daniel Henrique Barboza (2): virpcimock.c: mock /dev/vfio virpcimock.c: simplify getrealpath() usage Shivaprasad G Bhat (3): virpcimock: Mock the SRIOV Virtual functions tests: Add test case for QEMU pci-hostdev hotplug tests: Add a baseline test for multifunction pci device use case src/util/virprocess.h | 2 +- tests/Makefile.am | 7 + tests/qemuhotplugtest.c | 40 ++- .../qemuhotplug-hostdev-pci.xml | 6 + .../qemuhotplug-base-live+hostdev-pci.xml | 58 +++++ ...uhotplug-pseries-base-live+hostdev-pci.xml | 51 ++++ .../qemuhotplug-pseries-base-live.xml | 43 ++++ .../hostdev-pci-multifunction.args | 35 +++ .../hostdev-pci-multifunction.xml | 59 +++++ .../hostdev-vfio-multidomain.args | 2 +- .../hostdev-vfio-multidomain.xml | 2 +- tests/qemuxml2argvdata/hostdev-vfio.args | 2 +- tests/qemuxml2argvdata/hostdev-vfio.xml | 2 +- tests/qemuxml2argvdata/net-hostdev-fail.xml | 2 +- tests/qemuxml2argvdata/net-hostdev-vfio.args | 2 +- tests/qemuxml2argvdata/net-hostdev-vfio.xml | 2 +- tests/qemuxml2argvtest.c | 3 + .../hostdev-pci-multifunction.xml | 79 ++++++ tests/qemuxml2xmloutdata/hostdev-vfio.xml | 2 +- tests/qemuxml2xmloutdata/net-hostdev-vfio.xml | 2 +- tests/qemuxml2xmltest.c | 1 + tests/virpcimock.c | 232 +++++++++++++++--- tests/virpcitestdata/0000-06-12.0.config | Bin 0 -> 256 bytes tests/virpcitestdata/0000-06-12.1.config | Bin 0 -> 256 bytes tests/virpcitestdata/0000-06-12.2.config | Bin 0 -> 256 bytes tests/virprocessmock.c | 28 +++ 26 files changed, 611 insertions(+), 51 deletions(-) create mode 100644 tests/qemuhotplugtestdevices/qemuhotplug-hostdev-pci.xml create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-base-live+hostdev-pci.xml create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-pseries-base-live+hostdev-pci.xml create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-pseries-base-live.xml create mode 100644 tests/qemuxml2argvdata/hostdev-pci-multifunction.args create mode 100644 tests/qemuxml2argvdata/hostdev-pci-multifunction.xml create mode 100644 tests/qemuxml2xmloutdata/hostdev-pci-multifunction.xml create mode 100644 tests/virpcitestdata/0000-06-12.0.config create mode 100644 tests/virpcitestdata/0000-06-12.1.config create mode 100644 tests/virpcitestdata/0000-06-12.2.config create mode 100644 tests/virprocessmock.c -- 2.21.0

2 7

[libvirt] [PATCH v2 00/23] Use a slirp helper process
by marcandre.lureau＠redhat.com 06 Sep '19

06 Sep '19

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Hi, SLIRP networking can be running in a separate process. This allows for stricter security policies for QEMU & SLIRP, as SLIRP is notoriously not very safe (discussed on ML, various CVEs, and even the code says so explicitly in the comments), yet people rely on it for various reasons. With this series, for a network interface "user", libvirt will: - check the slirp-helper presence and capabilites (see [1]) - setup a socket pair between qemu and the helper - use -net socket - setup migration thanks to dbus-vmstate There are no changes required to domain configuration to benefit it. "guestfwd" isn't supported at this point, but it is known to be in a broken state with libvirt+qemu anyway. The dbus-vmstate is being proposed to QEMU. The libslirp-rs slirp-helper hasn't yet received a release. The current DBus p2p mode works ok, but is a hack. This is due to poor DBus support in Rust, and also relatively poor DBus p2p mode support in libdbus. fwiw, I have been working on an alternative rust-only implementation of a slirp-helper that will also follow [1], but I am now wondering if netstack or vpnkit could do the job. [1] https://gitlab.freedesktop.org/slirp/libslirp-rs/blob/master/src/bin/README… Marc-André Lureau (23): Add .editorconfig tests: fix xml2xml tpm-emulator.xml test dbus: correctly build reply message qemu: replace logCtxt with qemuDomainLogAppendMessage() qemu: add socket datagram capability qemu: add dbus-vmstate capability qemu: reset VM id after external devices stop qemu-security: add qemuSecurityCommandRun() qemu: add dbus-vmstate domain-conf: add network def private data qemu: add qemuDomainNetworkPrivate qemu-conf: add configurable slirp-helper location qemu-conf: add slirp state dir qemu: add slirp helper unit qemu-domain: save and restore slirp state qemu: add a flag to the cookie to prevent slirp-helper setup qemu-migration: prevent migration if dbus-vmstate is required qemu-migration: prevent migration if slirp cannot be migrated qemu-extdevice: prepare, start and stop slirp-helper qemu-command: use -net socket,fd= with slirp-helper qemu-process: prepare slirp-helper qemu-hotplug: handle hotplugging of slirp-helper tests: add slirp-helper qemuxml2argv test .editorconfig | 21 + m4/virt-driver-qemu.m4 | 5 + src/conf/domain_conf.c | 21 +- src/conf/domain_conf.h | 6 + src/qemu/Makefile.inc.am | 4 + src/qemu/libvirtd_qemu.aug | 1 + src/qemu/qemu.conf | 3 + src/qemu/qemu_alias.c | 17 + src/qemu/qemu_alias.h | 3 + src/qemu/qemu_capabilities.c | 8 + src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 118 ++++- src/qemu/qemu_command.h | 6 +- src/qemu/qemu_conf.c | 11 +- src/qemu/qemu_conf.h | 2 + src/qemu/qemu_dbus.c | 94 ++++ src/qemu/qemu_dbus.h | 42 ++ src/qemu/qemu_domain.c | 220 ++++++++- src/qemu/qemu_domain.h | 20 + src/qemu/qemu_driver.c | 8 + src/qemu/qemu_extdevice.c | 82 ++-- src/qemu/qemu_extdevice.h | 10 +- src/qemu/qemu_hotplug.c | 112 ++++- src/qemu/qemu_hotplug.h | 11 + src/qemu/qemu_interface.c | 27 ++ src/qemu/qemu_interface.h | 4 + src/qemu/qemu_migration.c | 19 + src/qemu/qemu_monitor.c | 13 +- src/qemu/qemu_monitor.h | 3 +- src/qemu/qemu_process.c | 24 +- src/qemu/qemu_security.c | 22 + src/qemu/qemu_security.h | 6 + src/qemu/qemu_slirp.c | 448 ++++++++++++++++++ src/qemu/qemu_slirp.h | 81 ++++ src/qemu/qemu_tpm.c | 4 +- src/qemu/test_libvirtd_qemu.aug.in | 1 + src/util/virdbus.c | 18 +- src/util/virdbus.h | 6 +- .../caps_4.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 + .../caps_4.0.0.riscv32.xml | 1 + .../caps_4.0.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.s390x.xml | 1 + .../caps_4.0.0.x86_64.xml | 1 + .../caps_4.1.0.x86_64.xml | 1 + .../net-user.x86_64-4.0.0.args | 34 ++ tests/qemuxml2argvdata/tpm-emulator.xml | 2 +- tests/qemuxml2argvtest.c | 16 + tests/testutilsqemu.h | 1 + tests/virfirewalltest.c | 9 +- tests/virpolkittest.c | 3 +- 51 files changed, 1498 insertions(+), 77 deletions(-) create mode 100644 .editorconfig create mode 100644 src/qemu/qemu_dbus.c create mode 100644 src/qemu/qemu_dbus.h create mode 100644 src/qemu/qemu_slirp.c create mode 100644 src/qemu/qemu_slirp.h create mode 100644 tests/qemuxml2argvdata/net-user.x86_64-4.0.0.args -- 2.23.0.rc1

3 48