- Devel - libvirt List Archives

RFC: Qemu backup interface plans
by Vladimir Sementsov-Ogievskiy 25 May '21

25 May '21

Hi all! I'd like to share and discuss some plans on Qemu backup interface I have. (actually, most of this I've presented on KVM Forum long ago.. But now I'm a lot closer to realization:) I'd start with a reminder about image fleecing: We have image fleecing scheme to export point-in-time state of active disk (iotest 222): backup(sync=none) ┌───────────────────────────────────────┐ ▼ │ ┌────────────┐ ┌────────────────┐ backing ┌─────────────┐ │ NBD export │ ─── │ temp qcow2 img │ ───────────────────▶ │ active disk │ └────────────┘ └────────────────┘ └─────────────┘ ▲ ┌────────────┐ │ │ guest blk │ ──────────────────────────────────────────────┘ └────────────┘ Actually, backup job inserts a backup-top filter, so in detail it looks like: backup(sync=none) ┌───────────────────────────────────────┐ ▼ │ ┌────────────┐ ┌────────────────┐ backing ┌─────────────┐ │ NBD export │ ─── │ temp qcow2 img │ ───────────────────▶ │ active disk │ └────────────┘ └────────────────┘ └─────────────┘ ▲ ▲ │ target │ │ │ ┌────────────┐ ┌────────────────┐ backing │ │ guest blk │ ──▶ │ backup-top │ ───────────────────────┘ └────────────┘ └────────────────┘ This scheme is also called external backup or pull backup. It allows some external tool to write data to actual backup, and Qemu only provides this data. We support also incremental external backup: Qemu can manage dirty bitmaps in any way user wants, and we can export bitmaps through NBD protocol. So, client of NBD export can get the bitmap, and read only "dirty" regions of exported image. What we lack in this scheme: 1. handling dirty bitmap in backup-top filter: backup-top does copy-before-write operation on any guest write, when actually we are interested only in "dirty" regions for incremental backup Probable solution would allowing specifying bitmap for sync=none mode of backup, but I think what I propose below is better. 2. [actually it's a tricky part of 1]: possibility to not do copy-before-write operations for regions that was already copied to final backup. With normal Qemu backup job, this is achieved by the fact that block-copy state with its internal bitmap is shared between backup job and copy-before-write filter. 3. Not a real problem but fact: backup block-job does nothing in the scheme, the whole job is done by filter. So, it would be interesting to have a possibility to simply insert/remove the filter, and avoid block-job creation and managing at all for external backup. (and I'd like to send another RFC on how to insert/remove filters, let's not discuss it here). Next. Think about internal backup. It has one drawback too: 4. If target is remote with slow connection, copy-before-write operations will slow down guest writes appreciably. It may be solved with help of image fleecing: we create temporary qcow2 image, setup fleecing scheme, and instead of exporting temp image through NBD we start a second backup with source = temporary image and target would be real backup target (NBD for example). Still, with such solution there are same [1,2] problems, 3 becomes worse: 5. We'll have two jobs and two automatically inserted filters, when actually one filter and one job are enough (as first job is needed only to insert a filter, second job doesn't need a filter at all). Note also, that this (starting two backup jobs to make push backup with fleecing) doesn't work now, op-blockers will be against. It's simple to fix (and in Virtuozzo we live with downstream-only patch, which allows push backup with fleecing, based on starting two backup jobs).. But I never send a patch, as I have better plan, which will solve all listed problems. So, what I propose: 1. We make backup-top filter public, so that it could be inserted/removed where user wants through QMP (how to properly insert/remove filter I'll post another RFC, as backup-top is not the only filter that can be usefully inserted somewhere). For this first step I've sent a series today: subject: [PATCH 00/21] block: publish backup-top filter id: <20210517064428.16223-1-vsementsov(a)virtuozzo.com> patchew: https://patchew.org/QEMU/20210517064428.16223-1-vsementsov@virtuozzo.com/ (note, that one of things in this series is rename s/backup-top/copy-before-write/, still, I call it backup-top in this letter) This solves [3]. [4, 5] are solved partly: we still have one extra filter, created by backup block jobs, and also I didn't test does this work, probably some op-blockers or permissions should be tuned. So, let it be step 2: 2. Test, that we can start backup job with source = (target of backup-top filter), so that we have "push backup with fleecing". Make an option for backup to start without a filter, when we don't need copy-before-write operations, to not create extra superfluous filter. 3. Support bitmap in backup-top filter, to solve [1] 3.1 and make it possible to modify the bitmap externally, so that consumer of fleecing can say to backup-top filter: I've already copied these blocks, don't bother with copying them to temp image". This is to solve [2]. Still, how consumer of fleecing will reset shared bitmap after copying blocks? I have the following idea: we make a "discard-bitmap-filter" filter driver, that own some bitmap and on discard request unset corresponding bits. Also, on read, if read from the region with unset bits the EINVAL returned immediately. This way both consumers (backup job and NBD client) are able to use this interface: Backup job can simply call discard on source, we can add an option for this. External backup tool will send TRIM request after reading some region. This way disk space will be freed and no extra copy-before-write operations will be done. I also have a side idea that we can implement READ_ONCE flag, so that READ and TRIM can be done in one NBD command. But this works only for clients that don't want to implement any kind of retrying. So, finally, how will it look (here I call backup-top with a new name, and "file" child is used instead of "backing", as this change I propose in "[PATCH 00/21] block: publish backup-top filter"): Pull backup: ┌────────────────────────────────────┐ │ NBD export │ └────────────────────────────────────┘ │ │ ┌────────────────────────────────────┐ file ┌───────────────────────────────────────┐ backing ┌─────────────┐ │ discard-bitmap filter (bitmap=bm0) │ ──────▶ │ temp qcow2 img │ ─────────▶ │ active disk │ └────────────────────────────────────┘ └───────────────────────────────────────┘ └─────────────┘ ▲ ▲ │ target │ │ │ ┌────────────────────────────────────┐ ┌───────────────────────────────────────┐ file │ │ guest blk │ ──────▶ │ copy-before-write filter (bitmap=bm0) │ ─────────────┘ └────────────────────────────────────┘ └───────────────────────────────────────┘ Operations: - Create temp qcow2 image - blockdev-add to add the new image, setup its backing, and add two filters - some command to actually set backup-top filter as child of guest blk. That's a "point-in-time" of backup. Should be done during fs-freeze. - start NBD export on top of discard filter (and we can export bitmap bm0 as well, for the client) Now NBD client (our external backup tool) can: - import the bitmap - READ the data - send DISCARD requests on already handled areas to save disk space and avoid extra copy-before-write operations on host node Push backup with fleecing: ┌─────────────────────┐ │ final backup target │ └─────────────────────┘ ▲ │ backup job (bitmap=bm0, insert-filter=False, discard-source=True) │ ┌────────────────────────────────────┐ file ┌───────────────────────────────────────┐ backing ┌─────────────┐ │ discard-bitmap filter (bitmap=bm0) │ ──────▶ │ temp qcow2 img │ ─────────▶ │ active disk │ └────────────────────────────────────┘ └───────────────────────────────────────┘ └─────────────┘ ▲ ▲ │ target │ │ │ ┌────────────────────────────────────┐ ┌───────────────────────────────────────┐ file │ │ guest blk │ ──────▶ │ copy-before-write filter (bitmap=bm0) │ ─────────────┘ └────────────────────────────────────┘ └───────────────────────────────────────┘ Note, that the whole fleecing part is the same, we only need to run backup job instead of NBD export. Additional future idea. Why we need push backup with fleecing? To handle cases with slow connection to backup target. In any case when writing to remote target is slower than writing to local file, push-backup-with-fleecing will less disturb the running guest than simple backup job. But this is not free: 1. We need additional disk space on source. No way to fix that (that's a core idea of the scheme, store data locally), still discard-source option for backup job will help 2. If connection is not too slow than probably part of CBW (copy before write) operations could go to final target immediately. But with the scheme above all CBW operations go to qcow2 temporary image. This can be solved with help of ram-cache format driver (to be implemented, of course): ┌─────────────────────┐ │ final backup target │ └─────────────────────┘ ▲ │ backup job (bitmap=bm0, insert-filter=False, discard-source=True) │ ┌────────────────────────────────────┐ ┌───────────────────────────────────────┐ backing ┌─────────────┐ │ discard-bitmap filter (bitmap=bm0) │ │ temp qcow2 img │ ─────────▶ │ active disk │ └────────────────────────────────────┘ └───────────────────────────────────────┘ └─────────────┘ │ ▲ ▲ │ │ file │ │ │ │ │ file ┌───────────┐ │ └───────────▶ │ ram-cache │ │ └───────────┘ │ ▲ │ │ target │ │ │ ┌────────────────────────────────────┐ ┌───────────────────────────────────────┐ file │ │ guest blk │ ──────▶ │ copy-before-write filter (bitmap=bm0) │ ─────────────┘ └────────────────────────────────────┘ └───────────────────────────────────────┘ This way data from copy-before-write filter goes first to ram-cache, and backup job could read it from ram. ram-cache will automatically flush data to temp qcow2 image, when ram-usage limit is reached. We'll also need a way to say backup-job that it should first read clusters that are cached in ram, and only then other clusters. So, we'll have a priory for clusters to be copied by block-copy: 1. clusters in ram-cache 2. clusters not in temp img (to avoid copy-before-write operations in future) 3. clusters in temp img. This will be a kind of block_status() thing, that allows a block driver to give recommendations on sequence of reading to be effective. Not also, that there is another benefit of such thing: we'll implement this callback in qcow2 driver, so that backup will read clusters not in guest cluster order, but in host cluster order, to read more sequentially, which should bring better performance on rotating disks. -- Best regards, Vladimir

3 8

[libvirt PATCH 0/4] adjust max memlock limit when hotplugging a vDPA device
by Laine Stump 25 May '21

25 May '21

see patch 4 for the why. Found during testing of https://bugzilla.redhat.com/1939776 Laine Stump (4): qemu_hotplug.c: don't skip cleanup on failures of qemuDomainAttachNetDevice conf: new function virDomainNetRemoveByObj() qemu_hotplug.c: add net devices to the domain list earlier qemu: adjust the maxmemlock limit when hotplugging a vDPA device src/conf/domain_conf.c | 16 ++++++++++++++++ src/conf/domain_conf.h | 1 + src/libvirt_private.syms | 1 + src/qemu/qemu_hotplug.c | 41 +++++++++++++++++++++++++++++++--------- 4 files changed, 50 insertions(+), 9 deletions(-) -- 2.31.1

2 5

[PATCH 0/3] capabilities: Turn @cpus in _virCapsHostNUMACell into GArray
by Michal Privoznik 24 May '21

24 May '21

Honestly, I don't really like GArray-s. I find plain C arrays better (smaller memory footprint, direct access to items, no obscure g_array_*() bugs, fewer lines of code, etc.). But I'm posting these to stir discussion. However, 1/3 is still proper patch worth merging. Michal Prívozník (3): libxl: Break down an if() in libxlCapsInitNuma() capabilities: Turn @cpus in _virCapsHostNUMACell into GArray virCapabilitiesHostNUMAInitReal: Drop cleanup label src/conf/capabilities.c | 145 +++++++++++++++++---------------- src/conf/capabilities.h | 11 +-- src/libvirt_private.syms | 2 +- src/libxl/libxl_capabilities.c | 34 ++++---- src/test/test_driver.c | 12 +-- tests/testutils.c | 23 +++--- 6 files changed, 121 insertions(+), 106 deletions(-) -- 2.26.3

2 4

Ceph RBD Connection
by Mr. Gecko 24 May '21

24 May '21

Hello, I setup a Ceph Cluster on my system in hopes of using it with libvirtd, however I'm finding myself unable to have libvirtd make the connection. [root@server ~]# virsh pool-start "${CEPH_POOL}" error: Failed to start pool libvirt-pool error: failed to connect to the RADOS monitor on: localhost:6789,: No such file or directory I know that rbd is working as I am able to use it with the rbd utility. [root@server ~]# rbd list libvirt-pool Kolab [root@server ~]# rbd device map libvirt-pool/Kolab /dev/rbd0 [root@server ~]# lsblk /dev/rbd0 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT rbd0 253:0 0 20G 0 disk ├─rbd0p1 253:1 0 1G 0 part └─rbd0p2 253:2 0 19G 0 part The libvirtd logs are not providing any useful information on the issue, I tried changing log-level to 1 and enabling the log_filters/adding "1:rbd" to the log filters. I have tried both the libvirt version 7.3.0 in my repository and the bleeding edge with a compile from git. Both returns the same error. Any help in troubleshooting this issue? I'm somewhat new when it comes to all of this. Thank you, James Coleman

2 3

[PATCH] hw/arm/raspi: Remove deprecated raspi2/raspi3 aliases
by Philippe Mathieu-Daudé 24 May '21

24 May '21

Remove the raspi2/raspi3 machine aliases, deprecated since commit 155e1c82ed0. Signed-off-by: Philippe Mathieu-Daudé <f4bug(a)amsat.org> --- docs/system/deprecated.rst | 7 ------- docs/system/removed-features.rst | 7 +++++++ hw/arm/raspi.c | 2 -- 3 files changed, 7 insertions(+), 9 deletions(-) diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 80cae862528..7895bd4d849 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -238,13 +238,6 @@ this CPU is also deprecated. System emulator machines ------------------------ -Raspberry Pi ``raspi2`` and ``raspi3`` machines (since 5.2) -''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' - -The Raspberry Pi machines come in various models (A, A+, B, B+). To be able -to distinguish which model QEMU is implementing, the ``raspi2`` and ``raspi3`` -machines have been renamed ``raspi2b`` and ``raspi3b``. - Device options -------------- diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst index 29e90601a51..8a8b8ca627b 100644 --- a/docs/system/removed-features.rst +++ b/docs/system/removed-features.rst @@ -312,6 +312,13 @@ This machine has been renamed ``fuloong2e``. These machine types were very old and likely could not be used for live migration from old QEMU versions anymore. Use a newer machine type instead. +Raspberry Pi ``raspi2`` and ``raspi3`` machines (removed in 6.1) +'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +The Raspberry Pi machines come in various models (A, A+, B, B+). To be able +to distinguish which model QEMU is implementing, the ``raspi2`` and ``raspi3`` +machines have been renamed ``raspi2b`` and ``raspi3b``. + linux-user mode CPUs -------------------- diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c index 990509d3852..20bba0316f1 100644 --- a/hw/arm/raspi.c +++ b/hw/arm/raspi.c @@ -342,7 +342,6 @@ static void raspi2b_machine_class_init(ObjectClass *oc, void *data) MachineClass *mc = MACHINE_CLASS(oc); RaspiMachineClass *rmc = RASPI_MACHINE_CLASS(oc); - mc->alias = "raspi2"; rmc->board_rev = 0xa21041; raspi_machine_class_common_init(mc, rmc->board_rev); }; @@ -362,7 +361,6 @@ static void raspi3b_machine_class_init(ObjectClass *oc, void *data) MachineClass *mc = MACHINE_CLASS(oc); RaspiMachineClass *rmc = RASPI_MACHINE_CLASS(oc); - mc->alias = "raspi3"; rmc->board_rev = 0xa02082; raspi_machine_class_common_init(mc, rmc->board_rev); }; -- 2.26.3

3 4

[PATCH 0/4] conf: Deduplicate NUMA distance code
by Michal Privoznik 24 May '21

24 May '21

While the number of saved lines is not that great, it prepares the code for what I'm working on - exposing HMAT in capabilities XML. My idea is to reuse XML formatters there too so that mgmt app can just take whatever we produce in capabilities XML and paste it into domain XML. Michal Prívozník (4): capabilities: Rename siblings to distances numa_conf: Rename virDomainNumaDistance to virNumaDistance numa_conf: Expose virNumaDistance formatter conf: Deduplicate NUMA distance code src/conf/capabilities.c | 60 ++++++++++++++------------------ src/conf/capabilities.h | 13 +++---- src/conf/numa_conf.c | 63 ++++++++++++++++++---------------- src/conf/numa_conf.h | 10 ++++++ src/conf/virconftypes.h | 2 -- src/libvirt_private.syms | 1 + src/libxl/libxl_capabilities.c | 20 +++++------ 7 files changed, 83 insertions(+), 86 deletions(-) -- 2.26.3

3 12

[PATCH 00/35] qemu: Implement support for transient disk hotplug and backing store sharing
by Peter Krempa 24 May '21

24 May '21

This series refactors the qemu disk hotplug code so that it can be easily extended for hotplug of transient disks and then also used at startup to plug in disks where the users want to share the backing image. Masayoshi Mizuma (1): qemu_snapshot: Add the guest name to the transient disk path Peter Krempa (34): qemu: snapshot: Extract setup of snapshot disk definition for transient disks qemu: process: Setup transient disks only when starting a fresh VM qemuSnapshotDiskPrepareOne: Pass in qemuSnapshotDiskContext qemuSnapshotDiskContext: Store virQEMUDriverConfig in the struct qemuSnapshotDiskPrepareOne: Use data from qemuSnapshotDiskContext qemuSnapshotDiskCreate: Use 'cfg' from the qemuSnapshotDiskContext qemu: snapshot: move transient snapshot code to qemu_process qemu: Move 'bootindex' handling for disks out of command line formatter qemu: Move bootindex usage logic into qemuBuildDiskDeviceStr qemuxml2argvtest: Remove pointless tests for keywrapping on s390 qemu: Move iothread and s390 address validation for disk devices into the validator Replace virDomainDiskInsertPreAlloced by virDomainDiskInsert conf: remove virDomainDiskInsertPreAlloced qemuBlockStorageSourceChainData: Add handling of 'copy-on-read' filter layer qemuDomainAttachDiskGeneric: Move 'copy-on-read' handling to qemuBlockStorageSourceChainData qemuDomainRemoveDiskDevice: Move 'copy-on-read' handling to qemuBlockStorageSourceChainData qemuDomainAttachDeviceDiskLiveInternal: Absorb qemuDomainAttachUSBMassStorageDevice qemuDomainAttachDeviceDiskLiveInternal: Absorb qemuDomainAttachVirtioDiskDevice qemuDomainAttachDeviceDiskLiveInternal: Absorb qemuDomainAttachSCSIDisk qemuDomainAttachDeviceDiskLiveInternal: Simplify call to qemuDomainAttachDiskGeneric qemuDomainAttachDiskGeneric: Move setup of disk into qemuDomainAttachDeviceDiskLiveInternal qemu: hotplug: Move post-insertion steps of disk hotplug to qemuDomainAttachDeviceDiskLiveInternal qemuDomainAttachDiskGeneric: Fix whitespace qemuDomainAttachDiskGeneric: Refactor cleanup qemuDomainAttachDiskGeneric: Move PR helper attach into qemuDomainAttachDeviceDiskLiveInternal qemuDomainAttachDiskGeneric: Refactor rollback handling qemuDomainAttachDiskGeneric: Split up frontend and backend attachment qemu: Track creation of <transient> disk overlay individually qemuDomainAttachDiskGeneric: Implement hotplug of <transient> disk qemuDomainAttachDiskGeneric: Pass the qemu async job type qemuDomainAttachDiskGeneric: Export conf: Introduce 'shareBacking' for <transient> disks qemu: Allow <transient> disks with images shared accross VMs tests: Add qemuxml2argv and qemuxml2xml test for <transient shareBacking='yes'> docs/formatdomain.rst | 6 + docs/schemas/domaincommon.rng | 5 + src/conf/domain_conf.c | 33 +- src/conf/domain_conf.h | 3 +- src/libvirt_private.syms | 1 - src/libxl/libxl_driver.c | 4 +- src/lxc/lxc_driver.c | 6 +- src/qemu/qemu_block.c | 12 + src/qemu/qemu_block.h | 4 + src/qemu/qemu_command.c | 134 ++----- src/qemu/qemu_command.h | 1 - src/qemu/qemu_domain.c | 2 - src/qemu/qemu_domain.h | 11 +- src/qemu/qemu_hotplug.c | 335 +++++++++--------- src/qemu/qemu_hotplug.h | 6 + src/qemu/qemu_process.c | 203 ++++++++++- src/qemu/qemu_snapshot.c | 160 +++------ src/qemu/qemu_snapshot.h | 27 +- src/qemu/qemu_validate.c | 73 ++++ .../disk-transient.x86_64-4.1.0.err | 2 +- .../disk-transient.x86_64-latest.args | 4 +- tests/qemuxml2argvdata/disk-transient.xml | 6 + tests/qemuxml2argvtest.c | 8 - .../disk-transient.x86_64-latest.xml | 48 +++ tests/qemuxml2xmltest.c | 3 +- 25 files changed, 644 insertions(+), 453 deletions(-) create mode 100644 tests/qemuxml2xmloutdata/disk-transient.x86_64-latest.xml -- 2.31.1

3 72

[PATCH] kbase: Fix broken link of migration doc
by Han Han 24 May '21

24 May '21

Signed-off-by: Han Han <hhan(a)redhat.com> --- docs/kbase/index.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/kbase/index.rst b/docs/kbase/index.rst index d483ca94de..91083ee49d 100644 --- a/docs/kbase/index.rst +++ b/docs/kbase/index.rst @@ -66,4 +66,4 @@ Internals / Debugging `VM migration internals <migrationinternals.html>`__ VM migration implementation details, complementing the info in - `migration <migration.html>`__ + `migration <../migration.html>`__ -- 2.31.1

2 1

[libvirt PATCH v2 0/2] storage_driver: add support for cluster_size QCOW2 option
by Pavel Hrdina 22 May '21

22 May '21

Pavel Hrdina (2): storage: add support for QCOW2 cluster_size option storage_file: add support to probe cluster_size from QCOW2 images docs/formatstorage.html.in | 6 ++ docs/schemas/storagecommon.rng | 7 ++ docs/schemas/storagevol.rng | 3 + src/conf/storage_conf.c | 12 ++++ src/storage/storage_util.c | 8 +++ src/storage_file/storage_file_probe.c | 70 ++++++++++++++----- .../qcow2-clusterSize.argv | 6 ++ tests/storagevolxml2argvtest.c | 4 ++ .../vol-qcow2-clusterSize.xml | 17 +++++ .../vol-qcow2-clusterSize.xml | 17 +++++ tests/storagevolxml2xmltest.c | 1 + 11 files changed, 134 insertions(+), 17 deletions(-) create mode 100644 tests/storagevolxml2argvdata/qcow2-clusterSize.argv create mode 100644 tests/storagevolxml2xmlin/vol-qcow2-clusterSize.xml create mode 100644 tests/storagevolxml2xmlout/vol-qcow2-clusterSize.xml -- 2.31.1

3 6

Qemu block filter insertion/removal API
by Vladimir Sementsov-Ogievskiy 21 May '21

21 May '21

Hi all! I'd like to be sure that we know where we are going to. In blockdev-era where qemu user is aware about block nodes, all nodes have good names and controlled by user we can efficiently use block filters. We already have some useful filters: copy-on-read, throttling, compress. In my parallel series I make backup-top filter public and useful without backup block jobs. But now filters could be inserted only together with opening their child. We can specify filters in qemu cmdline, or filter can take place in the block node chain created by blockdev-add. Still, it would be good to insert/remove filters on demand. Currently we are going to use x-blockdev-reopen for this. Still it can't be used to insert a filter above root node (as x-blockdev-reopen can change only block node options and their children). In my series "[PATCH 00/21] block: publish backup-top filter" I propose (as Kevin suggested) to modify qom-set, so that it can set drive option of running device. That's not difficult, but it means that we have different scenario of inserting/removing filters: 1. filter above root node X: inserting: - do blockdev-add to add a filter (and specify X as its child) - do qom-set to set new filter as a rood node instead of X removing - do qom-set to make X a root node again - do blockdev-del to drop a filter 2. filter between two block nodes P and X. (For example, X is a backing child of P) inserting - do blockdev-add to add a filter (and specify X as its child) - do blockdev-reopen to set P.backing = filter remvoing - do blockdev-reopen to set P.backing = X - do blockdev-del to drop a filter And, probably we'll want transaction support for all these things. Is it OK? Or do we need some kind of additional blockdev-replace command, that can replace one node by another, so in both cases we will do inserting: - blockdev-add filter - blockdev-replace (make all parents of X to point to the new filter instead (except for the filter itself of course) removing - blockdev-replace (make all parante of filter to be parents of X instead) - blockdev-del filter It's simple to implement, and it seems for me that it is simpler to use. Any thoughts? -- Best regards, Vladimir

3 8

[PATCH v1] libxl: remove libxl_domain_build_info_init from libxlMakeDomBuildInfo
by Olaf Hering 21 May '21

21 May '21

The used libxl_domain_build_info, which is contained in libxl_domain_config, is owned and already initialized by the caller. Signed-off-by: Olaf Hering <olaf(a)aepfle.de> --- src/libxl/libxl_conf.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index 1fd0322b6a..3598ca395d 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -346,8 +346,6 @@ libxlMakeDomBuildInfo(virDomainDef *def, size_t i; size_t nusbdevice = 0; - libxl_domain_build_info_init(b_info); - if (hvm) { libxl_domain_build_info_init_type(b_info, LIBXL_DOMAIN_TYPE_HVM); } else if (pvh) {

2 1

[PATCH v1] libxl: remove libxl_domain_create_info_init from libxlMakeDomCreateInfo
by Olaf Hering 21 May '21

21 May '21

The passed libxl_domain_create_info is owned, and already initialized, by the caller. Signed-off-by: Olaf Hering <olaf(a)aepfle.de> --- src/libxl/libxl_conf.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index 8dc7e26cea..1fd0322b6a 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -129,8 +129,6 @@ libxlMakeDomCreateInfo(libxl_ctx *ctx, { char uuidstr[VIR_UUID_STRING_BUFLEN]; - libxl_domain_create_info_init(c_info); - if (def->os.type == VIR_DOMAIN_OSTYPE_HVM || def->os.type == VIR_DOMAIN_OSTYPE_XENPVH) { #ifdef WITH_XEN_PVH

2 1

[PATCH v2] libxl: adjust handling of libxl_device_disk objects
by Olaf Hering 21 May '21

21 May '21

libxl objects are supposed to be initialized and disposed. Correct the usage of libxl_device_disk objects which are allocated on the stack. Initialize each one prior usage, and dispose them once done. Adjust libxlMakeDisk to use an already initialized object, it is owned by the caller. Adjust libxlMakeDiskList to initialize the list of objects, before they are filled by libxlMakeDisk. In case of error, the objects are disposed by libxl_domain_config_dispose. Signed-off-by: Olaf Hering <olaf(a)aepfle.de> --- src/libxl/libxl_conf.c | 20 +++++--------------- src/libxl/libxl_driver.c | 6 ++++++ 2 files changed, 11 insertions(+), 15 deletions(-) diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index 3149ee3b4a..f29a28a841 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -1114,8 +1114,6 @@ libxlMakeDisk(virDomainDiskDef *l_disk, libxl_device_disk *x_disk) int format = virDomainDiskGetFormat(l_disk); int actual_type = virStorageSourceGetActualType(l_disk->src); - libxl_device_disk_init(x_disk); - if (actual_type == VIR_STORAGE_TYPE_NETWORK) { if (STRNEQ_NULLABLE(driver, "qemu")) { virReportError(VIR_ERR_OPERATION_INVALID, "%s", @@ -1265,26 +1263,18 @@ libxlMakeDiskList(virDomainDef *def, libxl_domain_config *d_config) { virDomainDiskDef **l_disks = def->disks; int ndisks = def->ndisks; - libxl_device_disk *x_disks; size_t i; - x_disks = g_new0(libxl_device_disk, ndisks); + d_config->disks = g_new0(libxl_device_disk, ndisks); + d_config->num_disks = ndisks; for (i = 0; i < ndisks; i++) { - if (libxlMakeDisk(l_disks[i], &x_disks[i]) < 0) - goto error; + libxl_device_disk_init(&d_config->disks[i]); + if (libxlMakeDisk(l_disks[i], &d_config->disks[i]) < 0) + return -1; } - d_config->disks = x_disks; - d_config->num_disks = ndisks; - return 0; - - error: - for (i = 0; i < ndisks; i++) - libxl_device_disk_dispose(&x_disks[i]); - VIR_FREE(x_disks); - return -1; } /* diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index d54cd41785..2b844bb3b5 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -2978,6 +2978,7 @@ libxlDomainChangeEjectableMedia(virDomainObj *vm, virDomainDiskDef *disk) size_t i; int ret = -1; + libxl_device_disk_init(&x_disk); for (i = 0; i < vm->def->ndisks; i++) { if (vm->def->disks[i]->bus == disk->bus && STREQ(vm->def->disks[i]->dst, disk->dst)) { @@ -3018,6 +3019,7 @@ libxlDomainChangeEjectableMedia(virDomainObj *vm, virDomainDiskDef *disk) ret = 0; cleanup: + libxl_device_disk_dispose(&x_disk); virObjectUnref(cfg); return ret; } @@ -3030,6 +3032,7 @@ libxlDomainAttachDeviceDiskLive(virDomainObj *vm, virDomainDeviceDef *dev) libxl_device_disk x_disk; int ret = -1; + libxl_device_disk_init(&x_disk); switch (l_disk->device) { case VIR_DOMAIN_DISK_DEVICE_CDROM: ret = libxlDomainChangeEjectableMedia(vm, l_disk); @@ -3091,6 +3094,7 @@ libxlDomainAttachDeviceDiskLive(virDomainObj *vm, virDomainDeviceDef *dev) } cleanup: + libxl_device_disk_dispose(&x_disk); virObjectUnref(cfg); return ret; } @@ -3329,6 +3333,7 @@ libxlDomainDetachDeviceDiskLive(virDomainObj *vm, virDomainDeviceDef *dev) int idx; int ret = -1; + libxl_device_disk_init(&x_disk); switch (dev->data.disk->device) { case VIR_DOMAIN_DISK_DEVICE_DISK: if (dev->data.disk->bus == VIR_DOMAIN_DISK_BUS_XEN) { @@ -3380,6 +3385,7 @@ libxlDomainDetachDeviceDiskLive(virDomainObj *vm, virDomainDeviceDef *dev) } cleanup: + libxl_device_disk_dispose(&x_disk); virObjectUnref(cfg); return ret; }

2 1

[PATCH v2] conf: Report alias name of the detached device in error
by Kristina Hanicova 21 May '21

21 May '21

This is v2 from: https://listman.redhat.com/archives/libvir-list/2021-May/msg00481.html I have reworked the code a bit to have only one error report instead of multiple ones with different combinations of possible matching items. Suggested by Laine. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1942367 Signed-off-by: Kristina Hanicova <khanicov(a)redhat.com> --- src/conf/domain_conf.c | 67 ++++++++++++++++-------------------------- 1 file changed, 25 insertions(+), 42 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index b3ed3a9c5a..9631e40815 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -15645,6 +15645,12 @@ virDomainNetFindIdx(virDomainDef *def, virDomainNetDef *net) VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI); bool CCWAddrSpecified = virDomainDeviceAddressIsValid(&net->info, VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW); + g_autofree char *addr = NULL; + const char *macAddr = _("(<null>)"); + const char *alias = _("(<null>)"); + + if (MACAddrSpecified) + macAddr = virMacAddrFormat(&net->mac, mac); for (i = 0; i < def->nnets; i++) { if (MACAddrSpecified && @@ -15676,7 +15682,7 @@ virDomainNetFindIdx(virDomainDef *def, virDomainNetDef *net) if (MACAddrSpecified) { virReportError(VIR_ERR_OPERATION_FAILED, _("multiple devices matching MAC address %s found"), - virMacAddrFormat(&net->mac, mac)); + macAddr); } else { virReportError(VIR_ERR_OPERATION_FAILED, "%s", _("multiple matching devices found")); @@ -15688,47 +15694,24 @@ virDomainNetFindIdx(virDomainDef *def, virDomainNetDef *net) matchidx = i; } - if (matchidx < 0) { - if (MACAddrSpecified && PCIAddrSpecified) { - virReportError(VIR_ERR_DEVICE_MISSING, - _("no device matching MAC address %s found on " - VIR_PCI_DEVICE_ADDRESS_FMT), - virMacAddrFormat(&net->mac, mac), - net->info.addr.pci.domain, - net->info.addr.pci.bus, - net->info.addr.pci.slot, - net->info.addr.pci.function); - } else if (MACAddrSpecified && CCWAddrSpecified) { - virReportError(VIR_ERR_DEVICE_MISSING, - _("no device matching MAC address %s found on " - VIR_CCW_DEVICE_ADDRESS_FMT), - virMacAddrFormat(&net->mac, mac), - net->info.addr.ccw.cssid, - net->info.addr.ccw.ssid, - net->info.addr.ccw.devno); - } else if (PCIAddrSpecified) { - virReportError(VIR_ERR_DEVICE_MISSING, - _("no device found on " VIR_PCI_DEVICE_ADDRESS_FMT), - net->info.addr.pci.domain, - net->info.addr.pci.bus, - net->info.addr.pci.slot, - net->info.addr.pci.function); - } else if (CCWAddrSpecified) { - virReportError(VIR_ERR_DEVICE_MISSING, - _("no device found on " VIR_CCW_DEVICE_ADDRESS_FMT), - net->info.addr.ccw.cssid, - net->info.addr.ccw.ssid, - net->info.addr.ccw.devno); - } else if (MACAddrSpecified) { - virReportError(VIR_ERR_DEVICE_MISSING, - _("no device matching MAC address %s found"), - virMacAddrFormat(&net->mac, mac)); - } else { - virReportError(VIR_ERR_DEVICE_MISSING, "%s", - _("no matching device found")); - } - } - return matchidx; + if (matchidx >= 0) + return matchidx; + + if (net->info.alias) + alias = net->info.alias; + + if (CCWAddrSpecified) + addr = virDomainCCWAddressAsString(&net->info.addr.ccw); + else if (PCIAddrSpecified) + addr = virPCIDeviceAddressAsString(&net->info.addr.pci); + else + addr = g_strdup(_("(<null>)")); + + virReportError(VIR_ERR_DEVICE_MISSING, + _("no device found at address '%s' matching MAC address" + " '%s' and alias '%s'"), + addr, macAddr, alias); + return -1; } bool -- 2.31.1

3 2

[libvirt PATCH] Revert "qemuDomainSetNumaParamsLive: set nodeset for root cgroup"
by Pavel Hrdina 21 May '21

21 May '21

This reverts commit <1b22dd6dd44202094e0f78f887cbe790c00e9ebc>. First of all, the reverted commit is incomplete. It only sets cpuset.mems in the VM root cgroup when the API is used but there is no code that would do the same when the VM is started. Libvirt never places any process into the VM root cgroup directly. All the supporting processes like slirp-helper or dbus-daemon are placed into the emulator sub-cgroup and all the QEMU threads are distributed between emulator, vcpu* and iothread* sub-cgroups. The scenario described in the reverted commit can happen only if someone manually adds any process there which we should not care about. If we would like to set the limit in the VM root cgroup we need to introduce better logic: - set both (old and new) numa group in the VM root cgroup - change the numa group in all sub-cgroups to new value - finally set only the new value in the VM root cgroup The simplest fix now is to revert the commit. Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/qemu/qemu_driver.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index e10e699a1a..a972662c3f 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -8797,10 +8797,6 @@ qemuDomainSetNumaParamsLive(virDomainObj *vm, return -1; } - /* set nodeset for root cgroup */ - if (virCgroupSetCpusetMems(priv->cgroup, nodeset_str) < 0) - return -1; - return 0; } -- 2.31.1

2 1

RFC: qemu log permissions
by Kristina Hanicova 21 May '21

21 May '21

Hello everyone, I came across this issue: https://gitlab.com/libvirt/libvirt/-/issues/71 and I would like your opinion on implementing support to define mode (maybe even user/group/other?) in config, which the qemu log files would be created with. In this case, it is desired so that this tool 'Elasticsearch' can read logs. Is it worth implementing? What are your thoughts? Kristina

1 0

[PATCH] schema: Allow '0' offset for a <slice> of <disk>
by Peter Krempa 21 May '21

21 May '21

Using slice to cut off the end of the image is a perfectly vaid configuration. Use 'unsignedInt' instead of 'positiveInteger' for the 'offset' attribute in the XML schema and modify one test case to cover this use case. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1960993 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- docs/schemas/domaincommon.rng | 2 +- tests/qemuxml2argvdata/disk-slices.x86_64-latest.args | 2 +- tests/qemuxml2argvdata/disk-slices.xml | 2 +- tests/qemuxml2xmloutdata/disk-slices.x86_64-latest.xml | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index a2e5c50c1d..475f7f1a42 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -1638,7 +1638,7 @@ <define name="diskSourceSlice"> <attribute name="offset"> - <ref name="positiveInteger"/> + <ref name="unsignedInt"/> </attribute> <attribute name="size"> <ref name="positiveInteger"/> diff --git a/tests/qemuxml2argvdata/disk-slices.x86_64-latest.args b/tests/qemuxml2argvdata/disk-slices.x86_64-latest.args index d337ea91a7..f41bbeea09 100644 --- a/tests/qemuxml2argvdata/disk-slices.x86_64-latest.args +++ b/tests/qemuxml2argvdata/disk-slices.x86_64-latest.args @@ -28,7 +28,7 @@ XDG_CONFIG_HOME=/tmp/lib/domain--1-QEMUGuest1/.config \ -boot strict=on \ -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ -blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/raw.img","node-name":"libvirt-6-storage","auto-read-only":true,"discard":"unmap"}' \ --blockdev '{"node-name":"libvirt-6-format","read-only":false,"driver":"raw","offset":1234,"size":321,"file":"libvirt-6-storage"}' \ +-blockdev '{"node-name":"libvirt-6-format","read-only":false,"driver":"raw","offset":0,"size":321,"file":"libvirt-6-storage"}' \ -device virtio-blk-pci,bus=pci.0,addr=0x2,drive=libvirt-6-format,id=virtio-disk0,bootindex=1 \ -blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/raw.img","node-name":"libvirt-5-storage","auto-read-only":true,"discard":"unmap"}' \ -blockdev '{"driver":"raw","node-name":"libvirt-5-slice-sto","offset":9876,"size":123456789,"file":"libvirt-5-storage","auto-read-only":true,"discard":"unmap"}' \ diff --git a/tests/qemuxml2argvdata/disk-slices.xml b/tests/qemuxml2argvdata/disk-slices.xml index 1675766a46..016aa1b905 100644 --- a/tests/qemuxml2argvdata/disk-slices.xml +++ b/tests/qemuxml2argvdata/disk-slices.xml @@ -18,7 +18,7 @@ <driver name='qemu' type='raw'/> <source file='/var/lib/libvirt/images/raw.img'> <slices> - <slice type='storage' offset='1234' size='321'/> + <slice type='storage' offset='0' size='321'/> </slices> </source> <backingStore/> diff --git a/tests/qemuxml2xmloutdata/disk-slices.x86_64-latest.xml b/tests/qemuxml2xmloutdata/disk-slices.x86_64-latest.xml index 5c200ad31c..be5cd25084 100644 --- a/tests/qemuxml2xmloutdata/disk-slices.x86_64-latest.xml +++ b/tests/qemuxml2xmloutdata/disk-slices.x86_64-latest.xml @@ -21,7 +21,7 @@ <driver name='qemu' type='raw'/> <source file='/var/lib/libvirt/images/raw.img'> <slices> - <slice type='storage' offset='1234' size='321'/> + <slice type='storage' offset='0' size='321'/> </slices> </source> <backingStore/> -- 2.31.1

2 1

[PATCH v3 0/3] Introduce <input type='evdev'>
by Kristina Hanicova 21 May '21

21 May '21

This is v3 from: https://listman.redhat.com/archives/libvir-list/2021-May/msg00324.html v1 here: https://listman.redhat.com/archives/libvir-list/2021-April/msg01307.html Diff to v2: - Fixed formatting - Enable xml test call Kristina Hanicova (3): qemu_capabilities: Add QEMU_CAPS_INPUT_LINUX conf: Parse/format XML input type 'evdev' qemu: Build command line for object input-linux docs/formatdomain.rst | 37 ++++++---- docs/schemas/domaincommon.rng | 20 ++++++ src/conf/domain_audit.c | 1 + src/conf/domain_conf.c | 69 ++++++++++++++++--- src/conf/domain_conf.h | 12 ++++ src/conf/domain_validate.c | 8 +++ src/libvirt_private.syms | 2 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 2 + src/qemu/qemu_command.c | 33 ++++++++- src/qemu/qemu_domain_address.c | 1 + src/qemu/qemu_hotplug.c | 1 + src/qemu/qemu_validate.c | 6 ++ src/security/security_apparmor.c | 1 + src/security/security_dac.c | 2 + src/security/security_selinux.c | 2 + src/security/virt-aa-helper.c | 3 +- .../caps_2.11.0.s390x.xml | 1 + .../caps_2.11.0.x86_64.xml | 1 + .../caps_2.12.0.aarch64.xml | 1 + .../caps_2.12.0.ppc64.xml | 1 + .../caps_2.12.0.s390x.xml | 1 + .../caps_2.12.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_3.0.0.ppc64.xml | 1 + .../caps_3.0.0.riscv32.xml | 1 + .../caps_3.0.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_3.0.0.s390x.xml | 1 + .../caps_3.0.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_3.1.0.ppc64.xml | 1 + .../caps_3.1.0.x86_64.xml | 1 + .../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 + .../caps_4.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 + .../caps_4.2.0.x86_64.xml | 1 + .../caps_5.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 + .../caps_5.0.0.riscv64.xml | 1 + .../caps_5.0.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_5.1.0.sparc.xml | 1 + .../caps_5.1.0.x86_64.xml | 1 + .../caps_5.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 + .../caps_5.2.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 + .../caps_5.2.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../caps_6.1.0.x86_64.xml | 1 + .../input-linux.x86_64-latest.args | 34 +++++++++ tests/qemuxml2argvdata/input-linux.xml | 31 +++++++++ tests/qemuxml2argvtest.c | 2 + tests/qemuxml2xmloutdata/input-linux.xml | 1 + tests/qemuxml2xmltest.c | 2 + 61 files changed, 287 insertions(+), 24 deletions(-) create mode 100644 tests/qemuxml2argvdata/input-linux.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/input-linux.xml create mode 120000 tests/qemuxml2xmloutdata/input-linux.xml -- 2.31.1

2 5

[PATCH 0/2] qemu: auto-create <nvram> with defined permissions
by Kristina Hanicova 21 May '21

21 May '21

Kristina Hanicova (2): qemu: Use qemuDomainOpenFile() in qemuPrepareNVRAM() qemu: Return -EINVAL to keep qemuDomainOpenFile() consistent src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_process.c | 21 +++++++++++---------- 2 files changed, 12 insertions(+), 11 deletions(-) -- 2.31.1

2 3

[PATCH] qemu: Add check for needed paths for memory devices
by Kristina Hanicova 21 May '21

21 May '21

When building a commandline for a DIMM memory device with non-default access mode, the qemuBuildMemoryBackendProps() will tell QEMU to allocate memory from per-domain memory backing dir. But later, when preparing the host, the qemuProcessNeedMemoryBackingPath() does not check for memory devices at all resulting in per-domain memory backing dir not being created which upsets QEMU. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1961114 Signed-off-by: Kristina Hanicova <khanicov(a)redhat.com> --- src/qemu/qemu_process.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index b69a9d1927..35213f81ec 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -3938,6 +3938,11 @@ qemuProcessNeedMemoryBackingPath(virDomainDef *def, return true; } + for (i = 0; i < def->nmems; i++) { + if (def->mems[i]->access != VIR_DOMAIN_MEMORY_ACCESS_DEFAULT) + return true; + } + if (mem) { switch (mem->model) { case VIR_DOMAIN_MEMORY_MODEL_DIMM: -- 2.31.1

2 1

[PATCH 0/4] Support for launchSecurity type s390-pv
by Boris Fiuczynski 20 May '21

20 May '21

This patch series introduces the launch security type s390-pv. Specifying s390-pv as launch security type in an s390 domain prepares for running the guest in protected virtualization secure mode, also known as IBM Secure Execution. Boris Fiuczynski (4): conf: refactor launch security to allow more types qemu: add s390-pv-guest capability conf: add s390-pv as launch security type docs: add s390-pv documentation docs/formatdomain.rst | 7 + docs/kbase/s390_protected_virt.rst | 55 +++++- docs/schemas/domaincommon.rng | 13 +- src/conf/domain_conf.c | 164 +++++++++++------- src/conf/domain_conf.h | 14 +- src/conf/virconftypes.h | 2 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 4 +- src/qemu/qemu_command.c | 64 ++++++- src/qemu/qemu_driver.c | 2 +- src/qemu/qemu_firmware.c | 4 +- src/qemu/qemu_namespace.c | 21 ++- src/qemu/qemu_process.c | 36 +++- src/qemu/qemu_validate.c | 30 +++- src/security/security_dac.c | 4 +- .../launch-security-s390-pv-ignore-policy.xml | 24 +++ .../launch-security-s390-pv.xml | 18 ++ .../launch-security-s390-pv-ignore-policy.xml | 1 + tests/genericxml2xmltest.c | 2 + .../qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 + ...ty-s390-pv-ignore-policy.s390x-latest.args | 35 ++++ .../launch-security-s390-pv-ignore-policy.xml | 33 ++++ .../launch-security-s390-pv.s390x-latest.args | 35 ++++ .../launch-security-s390-pv.xml | 30 ++++ ...urity-sev-missing-policy.x86_64-2.12.0.err | 1 + .../launch-security-sev-missing-policy.xml | 34 ++++ tests/qemuxml2argvtest.c | 4 + 28 files changed, 538 insertions(+), 103 deletions(-) create mode 100644 tests/genericxml2xmlindata/launch-security-s390-pv-ignore-policy.xml create mode 100644 tests/genericxml2xmlindata/launch-security-s390-pv.xml create mode 120000 tests/genericxml2xmloutdata/launch-security-s390-pv-ignore-policy.xml create mode 100644 tests/qemuxml2argvdata/launch-security-s390-pv-ignore-policy.s390x-latest.args create mode 100644 tests/qemuxml2argvdata/launch-security-s390-pv-ignore-policy.xml create mode 100644 tests/qemuxml2argvdata/launch-security-s390-pv.s390x-latest.args create mode 100644 tests/qemuxml2argvdata/launch-security-s390-pv.xml create mode 100644 tests/qemuxml2argvdata/launch-security-sev-missing-policy.x86_64-2.12.0.err create mode 100644 tests/qemuxml2argvdata/launch-security-sev-missing-policy.xml -- 2.30.2

3 16

[PATCH v2] virNodeDevCapMdevParseXML: Use virXMLPropEnum() for ./start/@type
by Michal Privoznik 20 May '21

20 May '21

Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- v2 of: https://listman.redhat.com/archives/libvir-list/2021-May/msg00604.html diff to v1: - Switch from virXMLPropEnum() to virXMLPropEnumDefault() per Peter's review src/conf/node_device_conf.c | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c index 5598d420fe..af72e160a5 100644 --- a/src/conf/node_device_conf.c +++ b/src/conf/node_device_conf.c @@ -1919,7 +1919,7 @@ virNodeDevCapMdevParseXML(xmlXPathContextPtr ctxt, g_autofree xmlNodePtr *attrs = NULL; size_t i; g_autofree char *uuidstr = NULL; - g_autofree char *starttype = NULL; + xmlNodePtr startNode = NULL; ctxt->node = node; @@ -1941,17 +1941,15 @@ virNodeDevCapMdevParseXML(xmlXPathContextPtr ctxt, virUUIDFormat(uuidbuf, mdev->uuid); } - if ((starttype = virXPathString("string(./start[1]/@type)", ctxt))) { - int tmp; - if ((tmp = virNodeDevMdevStartTypeFromString(starttype)) < 0) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - _("unknown mdev start type '%s' for '%s'"), starttype, def->name); - return -1; - } + mdev->start = VIR_NODE_DEV_MDEV_START_MANUAL; - mdev->start = tmp; - } else { - mdev->start = VIR_NODE_DEV_MDEV_START_MANUAL; + startNode = virXPathNode("./start[1]", ctxt); + if (startNode && + virXMLPropEnumDefault(startNode, "type", + virNodeDevMdevStartTypeFromString, + VIR_XML_PROP_NONE, &mdev->start, + VIR_NODE_DEV_MDEV_START_MANUAL) < 0) { + return -1; } /* 'iommuGroup' is optional, only report an error if the supplied value is -- 2.26.3

3 2

[PATCH 0/4] Add win-dmp crashdump format
by Michal Privoznik 20 May '21

20 May '21

*** BLURB HERE *** Michal Prívozník (4): include: Fix copy-paste error in comment to virDomainCoreDumpFormat enum lib: Add win-dmp crashdump format virsh: Expose new win-dmp dump format NEWS: Document new memory dump format NEWS.rst | 5 +++++ docs/manpages/virsh.rst | 5 +++-- include/libvirt/libvirt-domain.h | 3 ++- src/qemu/qemu_driver.c | 1 + tools/virsh-domain.c | 2 ++ 5 files changed, 13 insertions(+), 3 deletions(-) -- 2.26.3

2 6

[PATCH 0/2] Remove static analysis cruft
by Peter Krempa 20 May '21

20 May '21

Remove comments for silencing coverity and static assers which are no longer needed. CI pipelines: Yesterday's all-green: https://gitlab.com/pipo.sk/libvirt/-/pipelines/305953275 New run started when I've rebased this to current master: https://gitlab.com/pipo.sk/libvirt/-/pipelines/306458103 Peter Krempa (2): Drop magic comments for coverity Remove static analysis assertions src/conf/domain_conf.c | 13 ------------- src/conf/virdomainobjlist.c | 2 -- src/conf/virnwfilterbindingobjlist.c | 1 - src/cpu/cpu_x86.c | 1 - src/libxl/libxl_driver.c | 9 --------- src/qemu/qemu_command.c | 2 -- src/qemu/qemu_driver.c | 2 -- src/qemu/qemu_monitor.c | 3 --- src/qemu/qemu_process.c | 2 -- src/remote/remote_driver.c | 1 - src/rpc/virnetserver.c | 4 ---- src/storage/parthelper.c | 2 -- src/util/vircommand.c | 3 --- src/util/virconf.c | 6 ------ src/util/virhostmem.c | 2 -- src/util/virnetdev.c | 1 - src/util/virobject.c | 1 - src/util/virprocess.c | 1 - src/util/virutil.c | 3 --- tests/commandtest.c | 2 -- tests/virdrivermoduletest.c | 1 - tools/virsh.c | 1 - tools/virt-admin.c | 1 - tools/vsh.c | 1 - 24 files changed, 65 deletions(-) -- 2.31.1

3 4

[PATCH] virNodeDevCapMdevParseXML: Use virXMLPropEnum() for ./start/@type
by Michal Privoznik 20 May '21

20 May '21

Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Initially, this started as a fix for broken build, but Peter beat me to it. I figured it's worth sending anyway. src/conf/node_device_conf.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c index 5598d420fe..d9b7aff7db 100644 --- a/src/conf/node_device_conf.c +++ b/src/conf/node_device_conf.c @@ -1919,7 +1919,7 @@ virNodeDevCapMdevParseXML(xmlXPathContextPtr ctxt, g_autofree xmlNodePtr *attrs = NULL; size_t i; g_autofree char *uuidstr = NULL; - g_autofree char *starttype = NULL; + xmlNodePtr startNode = NULL; ctxt->node = node; @@ -1941,17 +1941,14 @@ virNodeDevCapMdevParseXML(xmlXPathContextPtr ctxt, virUUIDFormat(uuidbuf, mdev->uuid); } - if ((starttype = virXPathString("string(./start[1]/@type)", ctxt))) { - int tmp; - if ((tmp = virNodeDevMdevStartTypeFromString(starttype)) < 0) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - _("unknown mdev start type '%s' for '%s'"), starttype, def->name); - return -1; - } + mdev->start = VIR_NODE_DEV_MDEV_START_MANUAL; - mdev->start = tmp; - } else { - mdev->start = VIR_NODE_DEV_MDEV_START_MANUAL; + startNode = virXPathNode("./start[1]", ctxt); + if (startNode && + virXMLPropEnum(startNode, "type", + virNodeDevMdevStartTypeFromString, + VIR_XML_PROP_NONE, &mdev->start) < 0) { + return -1; } /* 'iommuGroup' is optional, only report an error if the supplied value is -- 2.26.3

2 1