- Devel - libvirt List Archives

[PATCH 0/4] nodedev: adjust handling DASDs
by Boris Fiuczynski 20 Jun '24

20 Jun '24

Adjusting how DASDs are handled as recently ID_* tags are also included in the udev information which causes the problems reported by https://issues.redhat.com/browse/RHEL-39497 Removing the filtering of offline ccw devices as these devices are available in the system and also are used to set them online again. The state information is made available in the ccw capability as an optional state element. Boris Fiuczynski (4): nodedev: refactor storage type fixup nodedev: improve DASD detection nodedev: prevent invalid DASD node object creation nodedev: add ccw device state and remove fencing src/conf/node_device_conf.c | 24 +++++++++++++ src/conf/node_device_conf.h | 11 ++++++ src/conf/schemas/nodedev.rng | 8 +++++ src/node_device/node_device_udev.c | 56 +++++++++++++++++++++++++----- 4 files changed, 90 insertions(+), 9 deletions(-) -- 2.45.0

3 11

[RFC PATCH 0/1] support deprecated-props from query-cpu-model-expansion
by Collin Walling 19 Jun '24

19 Jun '24

Overview ======== QEMU will soon support reporting an optional array of deprecated features for an expanded CPU model via the query-cpu-model-expansion command. The intended use of this data is to make it easier for a user to define a CPU model with features flagged as deprecated set to disabled, thus rendering the guest migratable to future hardware that will out-right drop support for said features. Attached to this cover letter is only half of the bigger picture. I've updated the CPU model expansion ABI to parse the new array (if it's available) and store the result in a string list within the qemuMonitorCPUModelInfo struct. I also propose an approach on how to store/retrieve the list of deprecated features in the qemuCaps cache file. All feedback on this patch is certainly welcome. Please note: I do not provide any updates to the respective qemuCaps tests right now. The main goal of this post is to discuss the other half of the design: reporting and enabling a CPU model with deprecated features disabled. I believe the ideal solution involves a way for the user to easily configure their guest with this new data. Two ideas I currently have are outlined below. Other approaches are encouraged. Notes ===== - In my example below, I am running on a z14.2 machine. - The features that are flagged as deprecated for this model are: bpb, csske, cte, te. - The discussion regarding the QEMU changes can be found here: https://mail.gnu.org/archive/html/qemu-devel/2024-04/msg04605.html Example of Desired Changes ========================== Here is what I'd like the resulting guest's transient XML to look like for the <cpu> section (I have trimmed the features list for brevity): ... <cpu mode='custom' match='exact' check='partial'> <model fallback='forbid'>z14.2-base</model> <feature policy='require' name='aen'/> <feature policy='require' name='cmmnt'/> <feature policy='require' name='aefsi'/> ... <feature policy='disable' name='cte'/> *** <feature policy='require' name='ais'/> <feature policy='disable' name='bpb'/> *** <feature policy='require' name='ctop'/> <feature policy='require' name='gs'/> <feature policy='require' name='ppa15'/> <feature policy='require' name='zpci'/> <feature policy='require' name='sea_esop2'/> <feature policy='disable' name='te'/> *** <feature policy='require' name='cmm'/> <feature policy='disable' name='csske'/> *** </cpu> ... Ideas ===== New Host CPU Model ------------------ Create a new CPU model that is a mirror of the host CPU model with deprecated features turned off. Let's call this model "host-recommended". A user may define this model in the guest XML as they would any other CPU model: <cpu mode='host-recommended' check='partial'/> Just as how host-model works, anything defined nested in the <cpu> tag will be ignored. This model could potentially be listed in the domcapabilities output after the host-model: <cpu> <mode name='host-passthrough' supported='yes'> ... </mode> ... <mode name='host-model' supported='yes'> ... </mode> <mode name='host-recommended' supported='yes'> ... <feature policy='disable' name='cte'/> <feature policy='require' name='ais'/> <feature policy='disable' name='bpb'/> <feature policy='require' name='ctop'/> <feature policy='require' name='gs'/> <feature policy='require' name='ppa15'/> <feature policy='require' name='zpci'/> <feature policy='require' name='sea_esop2'/> <feature policy='disable' name='te'/> <feature policy='require' name='cmm'/> <feature policy='disable' name='csske'/> </cpu> New Nested Element Under <cpu> ------------------------------ Create a new optional XML element nested under the <cpu> tag that may be used to disable deprecated features. This approach is more explicit compared to creating a new CPU model, and allows the user to disable these features when defining a specific model other than host-model. Here is an example of what the guest's defined XML for the CPU could look like: <cpu mode='host-model' check='partial'> <deprecated_features>off</deprecated_features> </cpu> However, a conflict arises with this approach: parameter priority. It would need to be discussed what the expected behavior should be if a user defines a guest with both a mode to disable deprecated features and any deprecated features listed with the 'require' policy, e.g.: <cpu mode='custom' match='exact' check='partial'> <model fallback='allow'>z13.2-base</model>  <deprecated_features>off</deprecated_features> <feature policy='require' name='csske'/> </cpu> Another conflict is setting this option to "on" would have no effect on the CPU model (I can't think of a reason why someone would want to explicitly enable these features). This may not communicate well to the user. To report these features, a <deprecatedProperties> tag could be added to the domcapabilities output using the same format I use in my proposed patch for the qemu capabilities file: <cpu> <mode name='host-passthrough' supported='yes'> ... </mode> ... <mode name='host-model' supported='yes'> ... </mode> <deprecatedProperties> <property name='bpb'/> <property name='te'/> <property name='cte'/> <property name='csske'/> </deprecatedProperties> </cpu> Please let me know your thoughts. Once an approach is agreed upon, I will begin development. Collin Walling (1): qemu: monitor: parse deprecated-props from query-cpu-model-expansion response src/qemu/qemu_capabilities.c | 30 ++++++++++++++++++++++++++++++ src/qemu/qemu_monitor.h | 2 ++ src/qemu/qemu_monitor_json.c | 29 ++++++++++++++++++++++++----- 3 files changed, 56 insertions(+), 5 deletions(-) -- 2.43.0

3 8

[PATCH] conf: Drop unused declaration
by Adam Julis 19 Jun '24

19 Jun '24

Remove unused declaration of the virDomainDiskFindByBusAndDst(). Signed-off-by: Adam Julis <ajulis(a)redhat.com> --- src/conf/domain_conf.h | 4 ---- 1 file changed, 4 deletions(-) diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index a06f015444..cdab6ef2da 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -3558,10 +3558,6 @@ void virDomainDiskSetFormat(virDomainDiskDef *def, int format); virDomainControllerDef * virDomainDeviceFindSCSIController(const virDomainDef *def, const virDomainDeviceDriveAddress *addr); -virDomainDiskDef *virDomainDiskFindByBusAndDst(virDomainDef *def, - int bus, - char *dst); - virDomainControllerDef *virDomainControllerDefNew(virDomainControllerType type); void virDomainControllerDefFree(virDomainControllerDef *def); G_DEFINE_AUTOPTR_CLEANUP_FUNC(virDomainControllerDef, virDomainControllerDefFree); -- 2.45.0

2 1

[PATCH v2 00/20] node_dev_udev: use workerpool and improve nodedev events
by Marc Hartmayer 19 Jun '24

19 Jun '24

When an udev event occurs for a mediated device (mdev) the mdev config data requires an update via mdevctl as the udev event does not contain all config data. This update needs to occur immediately and to be finished before the libvirt nodedev event is issued to keep the API usage reliable. Changelog: v1->v2: + squashed old patches 3 and 17 (comments from Jonathon and Boris) + added r-b's from Jonathon and Boris + worked in comments from Jonathon to old patch 15 + added comment why only one worker can currently be used + added patch `node_device_udev: remove incorrect G_GNUC_UNUSED` RFCv1->v1: + removed some of my own s-o-b's that were accidentally inserted in the RFC + added r-b's from Boris and Jonathon + worked in comments from Boris and Jonathon, but I did not inline "nodeDeviceDefResetMdevActiveConfig" as I'm not sure whether this improves the readability + reworked patch "[RFC PATCH v1 11/15] node_device_udev: Use `stateShutdownPrepare` and `stateShutdownWait`" + reworked patch "node_device_udev: Use a worker pool for processing events and emitting nodedev event" + added patches: - node_device_udev: Move responsibility to release `(init|udev)Thread` to `udevEventDataDispose` - node_device_udev: Fix leak of mdevctlLock, udevThreadCond, and mdevCtlMonitor - node_device_udev: nodeStateShutdownPrepare: Disconnect the signals explicitly - node_device_udev: Pass the driver state as parameter in prepartion for the next commit - node_device_udev: Add support for `g_autoptr` to `udevEventData - node_device_udev: Pass the `udevEventData` via parameter and use refcounting Boris Fiuczynski (3): nodedev: fix mdev add udev event data handling nodedev: immediate update of active config on udev events nodedev: reset active config data on udev remove event Marc Hartmayer (17): node_device_udev: Set @def to NULL node_device_udev: Remove the timeout if the data is disposed node_device_udev: Test for mdevctlTimeout != -1 node_device_udev: Don't take `mdevctlLock` for `mdevctl list` and add comments about locking node_device_udev: Take lock if `driver->privateData` is modified node_device_udev: Add prefix `udev` for udev related data node_device_udev: Inline `udevRemoveOneDevice` node_device_udev: Move responsibility to release `(init|udev)Thread` to `udevEventDataDispose` node_device_udev: Fix leak of mdevctlLock, udevThreadCond, and mdevCtlMonitors node_device_udev: Introduce and use `stateShutdownPrepare` and `stateShutdownWait` node_device_udev: nodeStateShutdownPrepare: Disconnect the signals explicitly node_device_udev: Pass the driver state as parameter in preparation for the next commit node_device_udev: Use a worker pool for processing events and emitting nodedev event node_device_udev: Make the code easier to read node_device_udev: Add support for `g_autoptr` to `udevEventData` node_device_udev: Pass the `udevEventData` via parameter and use refcounting node_device_udev: remove incorrect G_GNUC_UNUSED src/node_device/node_device_driver.h | 5 +- src/util/virmdev.h | 4 + src/conf/node_device_conf.c | 10 +- src/node_device/node_device_driver.c | 28 +- src/node_device/node_device_udev.c | 516 ++++++++++++++++++--------- src/test/test_driver.c | 11 +- src/util/virmdev.c | 20 ++ src/libvirt_private.syms | 2 + 8 files changed, 398 insertions(+), 198 deletions(-) base-commit: c38720b337f74337ec94c0fe2e97a7c2c57188ae -- 2.34.1

3 27

[PATCH 00/12] qemu: migration: Fix crashes when VM shutdowns itself during migration in active state
by Peter Krempa 19 Jun '24

19 Jun '24

The daemon crashes due to unexpected cleanup happening due to bad assumptions about locking and state. See patch 5. Peter Krempa (12): qemuBlockJobProcessEventConcludedBackup: Handle potentially NULL 'job->disk' qemuDomainDiskPrivateDispose: Prevent dangling 'disk' pointer in blockjob data qemuDomainDeviceBackendChardevForeach: Fix typo in comment qemuDomainObjWait: Add documentation qemuProcessStop: Prevent crash when qemuDomainObjStopWorker() unlocks the VM qemuProcessStop: Move code not depending on 'vm->def->id' after reset of the ID qemu: process: Ensure that 'beingDestroyed' gets cleared only after VM id is reset qemu: domain: Introduce qemuDomainObjIsActive helper qemu: migration: Properly check for live VM after qemuDomainObjWait() qemu: migration: Inline 'qemuMigrationDstFinishResume()' qemuMigrationSrcRun: Re-check whether VM is active before accessing job data qemu: migration: Preserve error across qemuDomainSetMaxMemLock() on error paths src/qemu/qemu_backup.c | 6 +-- src/qemu/qemu_backup.h | 2 +- src/qemu/qemu_blockjob.c | 9 +++- src/qemu/qemu_domain.c | 40 +++++++++++++- src/qemu/qemu_domain.h | 2 + src/qemu/qemu_migration.c | 43 +++++++--------- src/qemu/qemu_process.c | 106 ++++++++++++++++++++++---------------- 7 files changed, 131 insertions(+), 77 deletions(-) -- 2.45.2

2 15

[PATCH] qemu: Don't specify vfio-pci.ramfb when ramfb is false
by Jonathon Jongsma 19 Jun '24

19 Jun '24

Commit 7c8e606b64c73ca56d7134cb16d01257f39c53ef attempted to fix the specification of the ramfb property for vfio-pci devices, but it failed when ramfb is explicitly set to 'off'. This is because only the 'vfio-pci-nohotplug' device supports the 'ramfb' property. Since we use the base 'vfio-pci' device unless ramfb is enabled, attempting to set the 'ramfb' parameter to 'off' this will result in an error like the following: error: internal error: QEMU unexpectedly closed the monitor (vm='rhel'): 2024-06-06T04:43:22.896795Z qemu-kvm: -device {"driver":"vfio-pci","host":"0000:b1:00.4","id":"hostdev0","display":"on ","ramfb":false,"bus":"pci.7","addr":"0x0"}: Property 'vfio-pci.ramfb' not found. This also more closely matches what is done for mdev devices. Resolves: https://issues.redhat.com/browse/RHEL-28808 Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com> --- src/qemu/qemu_command.c | 6 ++++-- .../hostdev-pci-display-ramfb.x86_64-latest.args | 2 +- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 2d0eddc79e..1e9de6460e 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -4760,12 +4760,14 @@ qemuBuildPCIHostdevDevProps(const virDomainDef *def, g_autofree char *host = virPCIDeviceAddressAsString(&pcisrc->addr); const char *failover_pair_id = NULL; const char *driver = NULL; + /* 'ramfb' property must be omitted unless it's to be enabled */ + bool ramfb = pcisrc->ramfb == VIR_TRISTATE_SWITCH_ON; /* caller has to assign proper passthrough driver name */ switch (pcisrc->driver.name) { case VIR_DEVICE_HOSTDEV_PCI_DRIVER_NAME_VFIO: /* ramfb support requires the nohotplug variant */ - if (pcisrc->ramfb == VIR_TRISTATE_SWITCH_ON) + if (ramfb) driver = "vfio-pci-nohotplug"; else driver = "vfio-pci"; @@ -4798,7 +4800,7 @@ qemuBuildPCIHostdevDevProps(const virDomainDef *def, "p:bootindex", dev->info->effectiveBootIndex, "S:failover_pair_id", failover_pair_id, "S:display", qemuOnOffAuto(pcisrc->display), - "T:ramfb", pcisrc->ramfb, + "B:ramfb", ramfb, NULL) < 0) return NULL; diff --git a/tests/qemuxmlconfdata/hostdev-pci-display-ramfb.x86_64-latest.args b/tests/qemuxmlconfdata/hostdev-pci-display-ramfb.x86_64-latest.args index e6e538ef1c..a681504c3d 100644 --- a/tests/qemuxmlconfdata/hostdev-pci-display-ramfb.x86_64-latest.args +++ b/tests/qemuxmlconfdata/hostdev-pci-display-ramfb.x86_64-latest.args @@ -29,6 +29,6 @@ XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest2/.config \ -audiodev '{"id":"audio1","driver":"none"}' \ -vnc 127.0.0.1:0,audiodev=audio1 \ -device '{"driver":"vfio-pci-nohotplug","host":"0000:06:12.5","id":"hostdev0","display":"on","ramfb":true,"bus":"pci.0","addr":"0x2"}' \ --device '{"driver":"vfio-pci","host":"0000:06:13.6","id":"hostdev1","display":"off","ramfb":false,"bus":"pci.0","addr":"0x3"}' \ +-device '{"driver":"vfio-pci","host":"0000:06:13.6","id":"hostdev1","display":"off","bus":"pci.0","addr":"0x3"}' \ -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ -msg timestamp=on -- 2.45.1

2 2

[PATCH v2] Pass shutoff reason to release hook
by Swapnil Ingle 19 Jun '24

19 Jun '24

Sometimes in release hook it is useful to know if the VM shutdown was graceful or not. This is especially useful to do cleanup based on the VM shutdown failure reason in release hook. This patch proposes to use the last argument 'extra' to pass VM shutoff reason in the call to release hook. Making this change for Qemu and LXC. Signed-off-by: Swapnil Ingle <swapnil.ingle(a)nutanix.com> --- docs/hooks.rst | 49 +++++++++++++++++++++++++++++++++++++++-- src/lxc/lxc_process.c | 2 +- src/qemu/qemu_process.c | 2 +- 3 files changed, 49 insertions(+), 4 deletions(-) diff --git a/docs/hooks.rst b/docs/hooks.rst index 1dbc492bd4..cdcb161c7e 100644 --- a/docs/hooks.rst +++ b/docs/hooks.rst @@ -215,7 +215,30 @@ operation. There is no specific operation to indicate a "restart" is occurring. :: - /etc/libvirt/hooks/qemu guest_name release end - + /etc/libvirt/hooks/qemu guest_name release end <shutoff-reason> + + +-------------------+------------------------------------------------------------------+ + | Shutoff reason | Description | + +===================+==================================================================+ + | unknown | the reason is unknown | + +-------------------+------------------------------------------------------------------+ + | shutdown | normal shutdown | + +-------------------+------------------------------------------------------------------+ + | destroyed | forced poweroff | + +-------------------+------------------------------------------------------------------+ + | crashed | domain crashed | + +-------------------+------------------------------------------------------------------+ + | migrated | migrated to another host | + +-------------------+------------------------------------------------------------------+ + | saved | saved to a file | + +-------------------+------------------------------------------------------------------+ + | failed | domain failed to start | + +-------------------+------------------------------------------------------------------+ + | from snapshot | restored from a snapshot which was taken while domain was shutoff| + +-------------------+------------------------------------------------------------------+ + | daemon | daemon decides to kill domain during reconnection processing | + +-------------------+------------------------------------------------------------------+ + - :since:`Since 0.9.11`, the qemu hook script is also called at the beginning of incoming migration. It is called as: @@ -312,7 +335,29 @@ operation. There is no specific operation to indicate a "restart" is occurring. :: - /etc/libvirt/hooks/lxc guest_name release end - + /etc/libvirt/hooks/lxc guest_name release end <shutoff-reason> + + +-------------------+------------------------------------------------------------------+ + | Shutoff reason | Description | + +===================+==================================================================+ + | unknown | the reason is unknown | + +-------------------+------------------------------------------------------------------+ + | shutdown | normal shutdown | + +-------------------+------------------------------------------------------------------+ + | destroyed | forced poweroff | + +-------------------+------------------------------------------------------------------+ + | crashed | domain crashed | + +-------------------+------------------------------------------------------------------+ + | migrated | migrated to another host | + +-------------------+------------------------------------------------------------------+ + | saved | saved to a file | + +-------------------+------------------------------------------------------------------+ + | failed | domain failed to start | + +-------------------+------------------------------------------------------------------+ + | from snapshot | restored from a snapshot which was taken while domain was shutoff| + +-------------------+------------------------------------------------------------------+ + | daemon | daemon decides to kill domain during reconnection processing | + +-------------------+------------------------------------------------------------------+ - :since:`Since 0.9.13`, the lxc hook script is also called when the libvirtd daemon restarts and reconnects to previously running LXC processes. If the diff --git a/src/lxc/lxc_process.c b/src/lxc/lxc_process.c index 30ff4eb3d0..f5eb5383ec 100644 --- a/src/lxc/lxc_process.c +++ b/src/lxc/lxc_process.c @@ -244,7 +244,7 @@ static void virLXCProcessCleanup(virLXCDriver *driver, /* we can't stop the operation even if the script raised an error */ virHookCall(VIR_HOOK_DRIVER_LXC, vm->def->name, VIR_HOOK_LXC_OP_RELEASE, VIR_HOOK_SUBOP_END, - NULL, xml, NULL); + virDomainShutoffReasonTypeToString(reason), xml, NULL); } if (flags & VIR_LXC_PROCESS_CLEANUP_REMOVE_TRANSIENT) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 2c33ac3bf7..9de01b1a0d 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -8722,7 +8722,7 @@ void qemuProcessStop(virQEMUDriver *driver, /* we can't stop the operation even if the script raised an error */ virHookCall(VIR_HOOK_DRIVER_QEMU, vm->def->name, VIR_HOOK_QEMU_OP_RELEASE, VIR_HOOK_SUBOP_END, - NULL, xml, NULL); + virDomainShutoffReasonTypeToString(reason), xml, NULL); } virDomainObjRemoveTransientDef(vm); -- 2.45.2

2 1

[PATCH] Pass shutoff reason to release hook
by Swapnil Ingle 18 Jun '24

18 Jun '24

Sometimes in release hook it is useful to know if the VM shutdown was graceful or not. This is especially useful to do cleanup based on the VM shutdown failure reason in release hook. This patch proposes to use the last argument 'extra' to pass VM shutoff reason in the call to release hook. Signed-off-by: Swapnil Ingle <swapnil.ingle(a)nutanix.com> --- docs/hooks.rst | 24 +++++++++++++++++++++++- src/qemu/qemu_process.c | 2 +- 2 files changed, 24 insertions(+), 2 deletions(-) diff --git a/docs/hooks.rst b/docs/hooks.rst index 1dbc492bd4..e76208021a 100644 --- a/docs/hooks.rst +++ b/docs/hooks.rst @@ -312,7 +312,29 @@ operation. There is no specific operation to indicate a "restart" is occurring. :: - /etc/libvirt/hooks/lxc guest_name release end - + /etc/libvirt/hooks/lxc guest_name release end <shutoff-reason> + + +-------------------+------------------------------------------------------------------+ + | Shutoff reason | Description | + +===================+==================================================================+ + | unknown | the reason is unknown | + +-------------------+------------------------------------------------------------------+ + | shutdown | normal shutdown | + +-------------------+------------------------------------------------------------------+ + | destroyed | forced poweroff | + +-------------------+------------------------------------------------------------------+ + | crashed | domain crashed | + +-------------------+------------------------------------------------------------------+ + | migrated | migrated to another host | + +-------------------+------------------------------------------------------------------+ + | saved | saved to a file | + +-------------------+------------------------------------------------------------------+ + | failed | domain failed to start | + +-------------------+------------------------------------------------------------------+ + | from snapshot | restored from a snapshot which was taken while domain was shutoff| + +-------------------+------------------------------------------------------------------+ + | daemon | daemon decides to kill domain during reconnection processing | + +-------------------+------------------------------------------------------------------+ - :since:`Since 0.9.13`, the lxc hook script is also called when the libvirtd daemon restarts and reconnects to previously running LXC processes. If the diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 7ef7040a85..0a03685ca7 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -8716,7 +8716,7 @@ void qemuProcessStop(virQEMUDriver *driver, /* we can't stop the operation even if the script raised an error */ virHookCall(VIR_HOOK_DRIVER_QEMU, vm->def->name, VIR_HOOK_QEMU_OP_RELEASE, VIR_HOOK_SUBOP_END, - NULL, xml, NULL); + virDomainShutoffReasonTypeToString(reason), xml, NULL); } virDomainObjRemoveTransientDef(vm); -- 2.45.2

2 3

Plans for 10.5.0 release (freeze on Tuesday 25 Jun)
by Jiri Denemark 18 Jun '24

18 Jun '24

We are getting close to 10.5.0 release of libvirt. To aim for the release on Monday 01 Jul I suggest entering the freeze on Tuesday 25 Jun and tagging RC2 on Thursday 27 Jun. I hope this works for everyone. Jirka

1 0

[PATCH 0/2] qemu: implement iommu coldplug/unplug
by Adam Julis 18 Jun '24

18 Jun '24

Adam Julis (2): syms: Properly export virDomainIOMMUDefFree() qemu: implement iommu coldplug/unplug src/libvirt_private.syms | 1 + src/qemu/qemu_driver.c | 20 ++++++++++++++++++-- 2 files changed, 19 insertions(+), 2 deletions(-) -- 2.45.0

2 4