Re: [PATCH] failover: allow to pause the VM during the migration
by Laine Stump
On 9/30/21 1:09 PM, Laurent Vivier wrote:
> If we want to save a snapshot of a VM to a file, we used to follow the
> following steps:
>
> 1- stop the VM:
> (qemu) stop
>
> 2- migrate the VM to a file:
> (qemu) migrate "exec:cat > snapshot"
>
> 3- resume the VM:
> (qemu) cont
>
> After that we can restore the snapshot with:
> qemu-system-x86_64 ... -incoming "exec:cat snapshot"
> (qemu) cont
This is the basics of what libvirt does for a snapshot, and steps 1+2
are what it does for a "managedsave" (where it saves the snapshot to
disk and then terminates the qemu process, for later re-animation).
In those cases, it seems like this new parameter could work for us -
instead of explicitly pausing the guest prior to migrating it to disk,
we would set this new parameter to on, then directly migrate-to-disk
(relying on qemu to do the pause). Care will need to be taken to assure
that error recovery behaves the same though.
There are a couple of cases when libvirt apparently *doesn't* pause the
guest during the migrate-to-disk, both having to do with saving a
coredump of the guest. Since I really have no idea of how
common/important that is (or even if my assessment of the code is
correct), I'm Cc'ing this patch to libvir-list to make sure it catches
the attention of someone who knows the answers and implications.
> But when failover is configured, it doesn't work anymore.
>
> As the failover needs to ask the guest OS to unplug the card
> the machine cannot be paused.
>
> This patch introduces a new migration parameter, "pause-vm", that
> asks the migration to pause the VM during the migration startup
> phase after the the card is unplugged.
>
> Once the migration is done, we only need to resume the VM with
> "cont" and the card is plugged back:
>
> 1- set the parameter:
> (qemu) migrate_set_parameter pause-vm on
>
> 2- migrate the VM to a file:
> (qemu) migrate "exec:cat > snapshot"
>
> The primary failover card (VFIO) is unplugged and the VM is paused.
>
> 3- resume the VM:
> (qemu) cont
>
> The VM restarts and the primary failover card is plugged back
>
> The VM state sent in the migration stream is "paused", it means
> when the snapshot is loaded or if the stream is sent to a destination
> QEMU, the VM needs to be resumed manually.
>
> Signed-off-by: Laurent Vivier <lvivier(a)redhat.com>
> ---
> qapi/migration.json | 20 +++++++++++++++---
> include/hw/virtio/virtio-net.h | 1 +
> hw/net/virtio-net.c | 33 ++++++++++++++++++++++++++++++
> migration/migration.c | 37 +++++++++++++++++++++++++++++++++-
> monitor/hmp-cmds.c | 8 ++++++++
> 5 files changed, 95 insertions(+), 4 deletions(-)
>
> diff --git a/qapi/migration.json b/qapi/migration.json
> index 88f07baedd06..86284d96ad2a 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -743,6 +743,10 @@
> # block device name if there is one, and to their node name
> # otherwise. (Since 5.2)
> #
> +# @pause-vm: Pause the virtual machine before doing the migration.
> +# This allows QEMU to unplug a card before doing the
> +# migration as it depends on the guest kernel. (since 6.2)
> +#
> # Since: 2.4
> ##
> { 'enum': 'MigrationParameter',
> @@ -758,7 +762,7 @@
> 'xbzrle-cache-size', 'max-postcopy-bandwidth',
> 'max-cpu-throttle', 'multifd-compression',
> 'multifd-zlib-level' ,'multifd-zstd-level',
> - 'block-bitmap-mapping' ] }
> + 'block-bitmap-mapping', 'pause-vm' ] }
>
> ##
> # @MigrateSetParameters:
> @@ -903,6 +907,10 @@
> # block device name if there is one, and to their node name
> # otherwise. (Since 5.2)
> #
> +# @pause-vm: Pause the virtual machine before doing the migration.
> +# This allows QEMU to unplug a card before doing the
> +# migration as it depends on the guest kernel. (since 6.2)
> +#
> # Since: 2.4
> ##
> # TODO either fuse back into MigrationParameters, or make
> @@ -934,7 +942,8 @@
> '*multifd-compression': 'MultiFDCompression',
> '*multifd-zlib-level': 'uint8',
> '*multifd-zstd-level': 'uint8',
> - '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ] } }
> + '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ],
> + '*pause-vm': 'bool' } }
>
> ##
> # @migrate-set-parameters:
> @@ -1099,6 +1108,10 @@
> # block device name if there is one, and to their node name
> # otherwise. (Since 5.2)
> #
> +# @pause-vm: Pause the virtual machine before doing the migration.
> +# This allows QEMU to unplug a card before doing the
> +# migration as it depends on the guest kernel. (since 6.2)
> +#
> # Since: 2.4
> ##
> { 'struct': 'MigrationParameters',
> @@ -1128,7 +1141,8 @@
> '*multifd-compression': 'MultiFDCompression',
> '*multifd-zlib-level': 'uint8',
> '*multifd-zstd-level': 'uint8',
> - '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ] } }
> + '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ],
> + '*pause-vm': 'bool' } }
>
> ##
> # @query-migrate-parameters:
> diff --git a/include/hw/virtio/virtio-net.h b/include/hw/virtio/virtio-net.h
> index 824a69c23f06..a6c186e28b45 100644
> --- a/include/hw/virtio/virtio-net.h
> +++ b/include/hw/virtio/virtio-net.h
> @@ -210,6 +210,7 @@ struct VirtIONet {
> bool failover;
> DeviceListener primary_listener;
> Notifier migration_state;
> + VMChangeStateEntry *vm_state;
> VirtioNetRssData rss_data;
> struct NetRxPkt *rx_pkt;
> struct EBPFRSSContext ebpf_rss;
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index f205331dcf8c..c83364eac47b 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -39,6 +39,7 @@
> #include "migration/misc.h"
> #include "standard-headers/linux/ethtool.h"
> #include "sysemu/sysemu.h"
> +#include "sysemu/runstate.h"
> #include "trace.h"
> #include "monitor/qdev.h"
> #include "hw/pci/pci.h"
> @@ -3303,6 +3304,35 @@ static void virtio_net_migration_state_notifier(Notifier *notifier, void *data)
> virtio_net_handle_migration_primary(n, s);
> }
>
> +static void virtio_net_failover_restart_cb(void *opaque, bool running,
> + RunState state)
> +{
> + DeviceState *dev;
> + VirtIONet *n = opaque;
> + Error *err = NULL;
> + PCIDevice *pdev;
> +
> + if (!running) {
> + return;
> + }
> +
> + dev = failover_find_primary_device(n);
> + if (!dev) {
> + return;
> + }
> +
> + pdev = PCI_DEVICE(dev);
> + if (!pdev->partially_hotplugged) {
> + return;
> + }
> +
> + if (!failover_replug_primary(n, dev, &err)) {
> + if (err) {
> + error_report_err(err);
> + }
> + }
> +}
> +
> static bool failover_hide_primary_device(DeviceListener *listener,
> QemuOpts *device_opts)
> {
> @@ -3360,6 +3390,8 @@ static void virtio_net_device_realize(DeviceState *dev, Error **errp)
> device_listener_register(&n->primary_listener);
> n->migration_state.notify = virtio_net_migration_state_notifier;
> add_migration_state_change_notifier(&n->migration_state);
> + n->vm_state = qemu_add_vm_change_state_handler(
> + virtio_net_failover_restart_cb, n);
> n->host_features |= (1ULL << VIRTIO_NET_F_STANDBY);
> }
>
> @@ -3508,6 +3540,7 @@ static void virtio_net_device_unrealize(DeviceState *dev)
> if (n->failover) {
> device_listener_unregister(&n->primary_listener);
> remove_migration_state_change_notifier(&n->migration_state);
> + qemu_del_vm_change_state_handler(n->vm_state);
> }
>
> max_queues = n->multiqueue ? n->max_queues : 1;
> diff --git a/migration/migration.c b/migration/migration.c
> index bb909781b7f5..9c96986d4abf 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -901,6 +901,9 @@ MigrationParameters *qmp_query_migrate_parameters(Error **errp)
> s->parameters.block_bitmap_mapping);
> }
>
> + params->has_pause_vm = true;
> + params->pause_vm = s->parameters.pause_vm;
> +
> return params;
> }
>
> @@ -1549,6 +1552,11 @@ static void migrate_params_test_apply(MigrateSetParameters *params,
> dest->has_block_bitmap_mapping = true;
> dest->block_bitmap_mapping = params->block_bitmap_mapping;
> }
> +
> + if (params->has_pause_vm) {
> + dest->has_pause_vm = true;
> + dest->pause_vm = params->pause_vm;
> + }
> }
>
> static void migrate_params_apply(MigrateSetParameters *params, Error **errp)
> @@ -1671,6 +1679,10 @@ static void migrate_params_apply(MigrateSetParameters *params, Error **errp)
> QAPI_CLONE(BitmapMigrationNodeAliasList,
> params->block_bitmap_mapping);
> }
> +
> + if (params->has_pause_vm) {
> + s->parameters.pause_vm = params->pause_vm;
> + }
> }
>
> void qmp_migrate_set_parameters(MigrateSetParameters *params, Error **errp)
> @@ -1718,6 +1730,12 @@ void qmp_migrate_start_postcopy(Error **errp)
> " started");
> return;
> }
> +
> + if (s->parameters.pause_vm) {
> + error_setg(errp, "Postcopy cannot be started if pause-vm is on");
> + return;
> + }
> +
> /*
> * we don't error if migration has finished since that would be racy
> * with issuing this command.
> @@ -3734,13 +3752,27 @@ static void qemu_savevm_wait_unplug(MigrationState *s, int old_state,
> "failure");
> }
> }
> -
> migrate_set_state(&s->state, MIGRATION_STATUS_WAIT_UNPLUG, new_state);
> } else {
> migrate_set_state(&s->state, old_state, new_state);
> }
> }
>
> +/* stop the VM before starting the migration but after device unplug */
> +static void pause_vm_after_unplug(MigrationState *s)
> +{
> + if (s->parameters.pause_vm) {
> + qemu_mutex_lock_iothread();
> + qemu_system_wakeup_request(QEMU_WAKEUP_REASON_OTHER, NULL);
> + s->vm_was_running = runstate_is_running();
> + if (vm_stop_force_state(RUN_STATE_PAUSED)) {
> + migrate_set_state(&s->state, MIGRATION_STATUS_ACTIVE,
> + MIGRATION_STATUS_FAILED);
> + }
> + qemu_mutex_unlock_iothread();
> + }
> +}
> +
> /*
> * Master migration thread on the source VM.
> * It drives the migration and pumps the data down the outgoing channel.
> @@ -3790,6 +3822,8 @@ static void *migration_thread(void *opaque)
> qemu_savevm_wait_unplug(s, MIGRATION_STATUS_SETUP,
> MIGRATION_STATUS_ACTIVE);
>
> + pause_vm_after_unplug(s);
> +
> s->setup_time = qemu_clock_get_ms(QEMU_CLOCK_HOST) - setup_start;
>
> trace_migration_thread_setup_complete();
> @@ -4265,6 +4299,7 @@ static void migration_instance_init(Object *obj)
> params->has_announce_max = true;
> params->has_announce_rounds = true;
> params->has_announce_step = true;
> + params->has_pause_vm = true;
>
> qemu_sem_init(&ms->postcopy_pause_sem, 0);
> qemu_sem_init(&ms->postcopy_pause_rp_sem, 0);
> diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
> index b5e71d9e6f52..71bc8c15335b 100644
> --- a/monitor/hmp-cmds.c
> +++ b/monitor/hmp-cmds.c
> @@ -513,6 +513,10 @@ void hmp_info_migrate_parameters(Monitor *mon, const QDict *qdict)
> }
> }
> }
> +
> + monitor_printf(mon, "%s: %s\n",
> + MigrationParameter_str(MIGRATION_PARAMETER_PAUSE_VM),
> + params->pause_vm ? "on" : "off");
> }
>
> qapi_free_MigrationParameters(params);
> @@ -1399,6 +1403,10 @@ void hmp_migrate_set_parameter(Monitor *mon, const QDict *qdict)
> error_setg(&err, "The block-bitmap-mapping parameter can only be set "
> "through QMP");
> break;
> + case MIGRATION_PARAMETER_PAUSE_VM:
> + p->has_pause_vm = true;
> + visit_type_bool(v, param, &p->pause_vm, &err);
> + break;
> default:
> assert(0);
> }
>
3 years, 2 months
translating CD-ROM device paths from i440fx to Q35 in virt-v2v (was: test-v2v-cdrom: update the CD-ROM's bus to SATA in the converted domain)
by Laszlo Ersek
(+libvirt-devel)
On 09/29/21 21:22, Richard W.M. Jones wrote:
> We currently partially install the virtio block drivers in the Windows
> guest (just enough to get the guest to boot on the target), and
> Windows itself re-installs the virtio block driver and other drivers
> it needs, and that's enough to get it to see C:
>
> As for other hard disk partitions, Windows does indeed contain a
> mapping to other drives in the Registry but IIRC it's not sensitive to
> the device driver (unlike Linux /dev/vdX vs /dev/sdX). If you're
> interested in that, see libguestfs.git/daemon/inspect_fs_windows.ml:
> get_drive_mappings. We never bothered with attempting to handle
> conversion of floppy drives or CD-ROMs for Windows.
OK. So AIUI, that means no work is needed here for Windows.
> On Linux we do better: We iterate over all the configuration files in
> /etc and change device paths. The significance of this bug is we need
> to change (eg) /dev/hdc to /dev/<something>. The difficulty is
> working out where the device will appear on the target and not having
> it conflict with any hard disk, something we partly control (see
> virt-v2v.git/convert/target_bus_assignment.ml*)
AIUI the conflict avoidance logic ("no overlapping disks") is already in
place. The question is how to translate device paths in /etc/fstab and
similar.
Please correct me if I'm wrong: at the moment, I believe virt-v2v parses
and manipulates the following elements and attributes in the domain XML:
<target dev='hda' bus='ide'/>
<target dev='hdb' bus='ide'/>
<target dev='hdc' bus='ide'/>
<target dev='hdd' bus='ide'/>
^^^ ^^^
My understanding is however that the target/@dev attribute is mostly
irrelevant:
https://libvirt.org/formatdomain.html#hard-drives-floppy-disks-cdroms
The dev attribute indicates the "logical" device name. The actual
device name specified is not guaranteed to map to the device name in
the guest OS. Treat it as a device ordering hint. [...]
What actually matters is the target/@bus attribute, in combination with
the sibling element <address>. Such as:
<target dev='hda' bus='ide'/>
^^^
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
^ ^ ^
<target dev='hdb' bus='ide'/>
^^^
<address type='drive' controller='0' bus='0' target='0' unit='1'/>
^ ^ ^
<target dev='hdc' bus='ide'/>
^^^
<address type='drive' controller='0' bus='1' target='0' unit='0'/>
^ ^ ^
<target dev='hdd' bus='ide'/>
^^^
<address type='drive' controller='0' bus='1' target='0' unit='1'/>
^ ^ ^
So, target/@dev should be mostly ignored; what matters is the following
tuple:
(target/@bus, address/@controller, address/@bus, address/@unit)
Extracting just the tuples:
(ide, 0, 0, 0)
(ide, 0, 0, 1)
(ide, 0, 1, 0)
(ide, 0, 1, 1)
The first two components of each tuple -- i.e., (ide, 0) -- refer to the
following IDE controller:
<controller type='ide' index='0'>
^^^^^^^^^^ ^^^^^^^^^
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
</controller>
and then the rest of the components, such as (0, 0), (0, 1), (1, 0), (1,
1), identify the disk on that IDE controller.
(Side comment: the PCI location of the (first) IDE controller is fixed
in QEMU; if one tries to change it, libvirt complains: "Primary IDE
controller must have PCI address 0:0:1.1".)
(Side comment: on the QEMU command line, this maps to
-device ide-cd,bus=ide.0,unit=0,... \
-device ide-cd,bus=ide.0,unit=1,... \
-device ide-cd,bus=ide.1,unit=0,... \
-device ide-cd,bus=ide.1,unit=1,... \
)
Inside the guest, /dev/hd* nodes don't even exist, so it's unlikely that
/etc/fstab would refer to them. /etc/fstab can however refer to symlinks
under "/dev/disk/by-id" (for example):
lrwxrwxrwx. 1 root root 9 Sep 30 11:54 ata-QEMU_DVD-ROM_QM00001 -> ../../sr0
lrwxrwxrwx. 1 root root 9 Sep 30 11:54 ata-QEMU_DVD-ROM_QM00002 -> ../../sr1
lrwxrwxrwx. 1 root root 9 Sep 30 11:54 ata-QEMU_DVD-ROM_QM00003 -> ../../sr2
lrwxrwxrwx. 1 root root 9 Sep 30 11:54 ata-QEMU_DVD-ROM_QM00004 -> ../../sr3
Furthermore, we have pseudo-files (directories) such as:
/sys/devices/pci0000:00/0000:00:01.1/ata1/host0/target0:0:0/0:0:0:0/block/sr0
/sys/devices/pci0000:00/0000:00:01.1/ata1/host0/target0:0:1/0:0:1:0/block/sr1
/sys/devices/pci0000:00/0000:00:01.1/ata2/host1/target1:0:0/1:0:0:0/block/sr2
/sys/devices/pci0000:00/0000:00:01.1/ata2/host1/target1:0:1/1:0:1:0/block/sr3
^ ^
So in order to map a device path from the original guest's "/etc/fstab",
such as "/dev/disk/by-id/ata-QEMU_DVD-ROM_QM00003", to the original
domain XML's <disk> element, we have to do the following in the "source"
appliance:
NODE=$(realpath /dev/disk/by-id/ata-QEMU_DVD-ROM_QM00003)
# -> /dev/sr2
NODE=${NODE#/dev/}
# -> sr2
DEVPATH=$(ls -d /sys/devices/pci0000:00/0000:00:01.1/ata?/host?/target?:0:?/?:0:?:0/block/$NODE)
# -> /sys/devices/pci0000:00/0000:00:01.1/ata2/host1/target1:0:0/1:0:0:0/block/sr2
And then map the "1:0:0:0" pathname component from $DEVPATH to:
<target dev='hdc' bus='ide'/>
<address type='drive' controller='0' bus='1' target='0' unit='0'/>
^^^^^^^ ^^^^^^^^
[1]:0:0:0 1:0:[0]:0
in the original domain XML. This tells us under what device node the
original guest sees the host-side file (<source> element).
After conversion, on the Q35 board, the inverse mapping is needed. We
start from the domain XML,
<target dev='sd*' bus='sata'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
<target dev='sd*' bus='sata'/>
<address type='drive' controller='0' bus='0' target='0' unit='1'/>
<target dev='sd*' bus='sata'/>
<address type='drive' controller='0' bus='0' target='0' unit='2'/>
<target dev='sd*' bus='sata'/>
<address type='drive' controller='0' bus='0' target='0' unit='3'/>
<target dev='sd*' bus='sata'/>
<address type='drive' controller='0' bus='0' target='0' unit='4'/>
<target dev='sd*' bus='sata'/>
<address type='drive' controller='0' bus='0' target='0' unit='5'/>
<controller type='sata' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
</controller>
(Side comment: the PCI B/D/F of the SATA controller is also fixed in
QEMU; otherwise libvirt complains: "Primary SATA controller must have
PCI address 0:0:1f.2".)
(Side comment: the QEMU command line is
-device ide-cd,bus=ide.0,... \
-device ide-cd,bus=ide.1,... \
-device ide-cd,bus=ide.2,... \
-device ide-cd,bus=ide.3,... \
-device ide-cd,bus=ide.4,... \
-device ide-cd,bus=ide.5,... \
)
In the guest we have:
/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sr0
/sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr1
/sys/devices/pci0000:00/0000:00:1f.2/ata3/host2/target2:0:0/2:0:0:0/block/sr2
/sys/devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sr3
/sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sr4
/sys/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sr5
So, assuming we mapped the original (i440fx)
"/dev/disk/by-id/ata-QEMU_DVD-ROM_QM00003" guest device path to some
<source> element (= host-side file) in the original domain XML, and
assuming virt-v2v assigned the same <source> element to the following
element on the Q35 board:
<target dev='sd*' bus='sata'/>
<address type='drive' controller='0' bus='0' target='0' unit='4'/>
^^^^^^^^
we find the device node in the destination appliance as follows:
NODE=$(basename /sys/devices/pci0000:00/0000:00:1f.2/ata?/host?/target?:0:0/4:0:0:0/block/*)
^
unit='4'
# -> sr4
and then replace "/dev/disk/by-id/ata-QEMU_DVD-ROM_QM00003" with
"/dev/sr4" in "/etc/fstab".
All this requires virt-v2v to parse complete <address> elements from the
original domain XML, and to generate complete <address> elements in the
destination domain XML. Is that feasible?
The @wwn and @serial attributes don't look safe to me, because the guest
could refer to them even when the original domain XML does not spell
them out (eg. "QM00003" is such a @serial). So neither can we trust that
a @serial is present in the original XML, nor can we just go ahead and
generate a @serial if it is absent. (The generation step could
immediately break references such as "QM00003" in the guest.)
/dev/disk/by-label and /dev/disk/by-uuid are based on media contents,
and multiple CD-ROMs may (read-only) map the same host-side file, so
those are not good for mapping either, I think. Also does not cover
CD-ROM devices that are empty (have no medium) at the time of
conversion, but "/etc/fstab" still refers to them (potentially with
"noauto"). So I think the only reliable ID is the hardware device path.
... Now if *that* needs to work when the original guest comes from a
different management application than libvirt, then I have no idea. The
original address (PCI B/D/F of the IDE controller, and IDE bus and unit
of the drive) need to be known somehow; otherwise we cannot associate
the guest-side "/dev/..." reference with the host-side file underlying
that CD-ROM.
Thanks,
Laszlo
3 years, 2 months
[PATCH v3 0/5] Add support for two i386 pm options which control acpi hotplug
by Ani Sinha
Hi all:
This patchset introduces libvirt xml support for the following two pm conf
options:
<pm>
<acpi-hotplug-bridge enabled='no'/>
<acpi-root-hotplug enabled='yes'/>
</pm>
The above two options are only available for qemu driver and that too for x86
guests only. Both of them are global options.
``acpi-hotplug-bridge`` option enables or disables ACPI hotplug support for cold
plugged bridges. Examples of cold plugged bridges include PCI-PCI bridge
(pci-bridge controller) for pc machines and pcie-root-port controller for q35
machines. The corresponding commandline options to qemu for x86 guests are:
(pc machines): -global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=<off/on>
(q35 machines): -global ICH9-LPC.acpi-pci-hotplug-with-bridge-support=<off/on>
Being global options, no other bridge specific options for pci-bridge
controller or pcie-root-port controllers are required. For pc machine type in
x86, this option is available in qemu for a long time, from version 2.1.
Please see the changes in qemu.git:
9e047b982452c6 ("piix4: add acpi pci hotplug support")
133a2da488062e ("pc: acpi: generate AML only for PCI0 devices if PCI bridge hotplug is disabled")
For q35 machine type, this was introduced in qemu 6.1 with the following
changes in qemu.git:
(a) c0e427d6eb5fef ("hw/acpi/ich9: Enable ACPI PCI hot-plug")
(b) 17858a16950860 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35")
The reasons for enabling ACPI based hotplug for PCIe (q35) based machines (as
opposed to native hotplug) for bridges are outlined in (b). It is possible that
some users might still want to use native hotplug on PCIe [1]. Therefore,
this conf option enables users to choose either ACPI based hotplug or native
hotplug for cold plugged bridges (for example for pcie root port controller
in q35 machines).
``acpi-root-hotplug`` option enables or disables ACPI based hotplug for PCI root
bus (pci-root controller). This option is only available for pc machine type.
The corresponding commandline option to qemu for x86 guests is:
-global PIIX4_PM.acpi-root-pci-hotplug=<off/on>
This additional option enables users to disable hotplug for all devices in the
system without adding an additional PCI-PCI bridge, putting the devices behind
the bridge and using the existing ``acpi-hotplug-bridge`` option to disable
hotplug on that bridge. This feature was introduced from qemu version 5.2 with
the following change in qemu.git:
3d7e78aa7777f ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus")
The above qemu commit describes some compelling reasons why users might to
disable hotplug on PCI root buses [2].
A brief summary of the patches:
>[PATCH v3 1/5] qemu: capablities: detect presence of
>[PATCH v3 2/5] qemu: capablities: detect presence of
Patches 1 and 2 implement support for qemu capability checks for the above
config options.
>[PATCH v3 3/5] conf: introduce acpi-hotplug-bridge and
Patch 3 actually adds the config option to the schema and adds related unit
tests.
>[PATCH v3 4/5] qemu: command: add support for qemu options that
Patch 4 adds the backend qemu commandline support for the options. It also adds
relevant unit tests for the same.
>[PATCH v3 5/5] NEWS: add new acpi pci hotplug options in the release
Patch 5 adds the release notes for the next libvirt release.
Changelog:
v1: initial implementation. Had some bugs and missed some unit tests.
v2: fixed bugs and added additional missing unit tests.
v3: reorganized the patches as per Laine's suggestion. Added more
details in commit messages. Added conf description in formatdomain.rst.
Added changelog for next release.
Notes:
[1] One concrete example of why one might still want to use native hotplug with
pcie-root-port controller is the fact that we are still discovering issues with
acpi hotplug on PCIE. One such issue is:
https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg02146.html
Another reason is that users have been using native hotplug on pcie root ports
up until now. They have built and tested their systems based on native hotplug.
They may not want to suddenly move to acpi based hotplug just because it is now
the default in qemu. Supporting the option to chose one or the other through
libvirt makes things simpler for end users.
[2] The use case scenario described by Laine in
https://listman.redhat.com/archives/libvir-list/2020-February/msg00110.html
intentionally does not discuss i440fx and focusses solely on q35. I do realize
that redhat has moved on from i440fx and currently efforts for new features
are concentrated on q35 machines only. We have had some hard debates on this
on the qemu mailing list before. The fact of the matter is that i440fx is
not at 1-1 parity with q35. There are many users who are currenly using i440fx
and are simply not ready to move to q35 without sacrificing some
existing features they support today. For example
https://wiki.qemu.org/images/4/4e/Q35.pdf lists some of q35 limitations.
https://www.linux-kvm.org/images/0/06/2012-forum-Q35.pdf provides more
information on the differences. Hence we need to solve the issue Laine has
described in the above email for i440fx without adding additional bridges.
Further, in Daniel Berrange's words from :
https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg03012.html
"From the upstream POV, there's been no decision / agreement to phase
out PIIX, this is purely a RHEL downstream decision & plan. If other
distros / users have a different POV, and find the feature useful, we
should accept the patch if it meets the normal QEMU patch requirements.
"
Also to be noted that I have already experimented this qemu commandline option
using libvirt passthrough feature as has been documented in
http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html
This was only meant to be a short term solution until libvirt started
supporting this natively. Supporting this option through libvirt would simplify
their use case as well as add capability validations
and graceful failure scenarios in case qemu did not support the option.
[3] Finally, I implemented support for ``acpi-root-hotplug`` option in Qemu.
Since adding the support for this option, I have not run away :-) I am still
around, fixing other issues in the same subsystem in qemu and also now I have
added myself as a reviewer of patches in this area. I will also be trying to
support/maintain this new xml conf option in libvirt to the extent I can in
future with the help of other experienced maintainers. Obviously this is all
freelance work at this moment and is highly dependent on available free time.
3 years, 2 months
[PATCH] qemuDomainChangeDiskLive: Modify 'startupPolicy' before changing source
by Peter Krempa
We don't support all startup policies with all source types so to
correctly allow switching from a 'file' based cdrom with 'optional'
startup policy to a 'block' based one which doesn't support optional we
must update the startup policy field first. Obviously we need to have
fallback if the update fails.
Reported-by: Vojtech Juranek <vjuranek(a)redhat.com>
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
src/qemu/qemu_driver.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index bd41ddbc3c..dfc27572c4 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -7038,6 +7038,7 @@ qemuDomainChangeDiskLive(virDomainObj *vm,
{
virDomainDiskDef *disk = dev->data.disk;
virDomainDiskDef *orig_disk = NULL;
+ virDomainStartupPolicy origStartupPolicy;
virDomainDeviceDef oldDev = { .type = dev->type };
if (!(orig_disk = virDomainDiskByTarget(vm->def, disk->dst))) {
@@ -7047,6 +7048,7 @@ qemuDomainChangeDiskLive(virDomainObj *vm,
}
oldDev.data.disk = orig_disk;
+ origStartupPolicy = orig_disk->startupPolicy;
if (virDomainDefCompatibleDevice(vm->def, dev, &oldDev,
VIR_DOMAIN_DEVICE_ACTION_UPDATE,
true) < 0)
@@ -7065,13 +7067,20 @@ qemuDomainChangeDiskLive(virDomainObj *vm,
return -1;
}
+ /* update startup policy first before updating disk image */
+ orig_disk->startupPolicy = dev->data.disk->startupPolicy;
+
if (qemuDomainChangeEjectableMedia(driver, vm, orig_disk,
- dev->data.disk->src, force) < 0)
+ dev->data.disk->src, force) < 0) {
+ /* revert startup policy before failing */
+ orig_disk->startupPolicy = origStartupPolicy;
return -1;
+ }
dev->data.disk->src = NULL;
}
+ /* in case when we aren't updating disk source we update startup policy here */
orig_disk->startupPolicy = dev->data.disk->startupPolicy;
orig_disk->snapshot = dev->data.disk->snapshot;
--
2.31.1
3 years, 2 months
[PATCH v4 0/4] introduce support for acpi-bridge-hotplug feature
by Ani Sinha
changelog:
v4: split the original series into two - pci-root controller specific one
(https://www.mail-archive.com/libvir-list@redhat.com/msg221645.html)
and this one specific to pci bridges.
The conf xml has been introduced as per suggestion by Berrange here:
https://patchew.org/Libvirt/20210912032631.2853520-1-ani@anisinha.ca
Changes has been introduced to parse and validate the xml accordingly
as well as to add backend qemu commandline option.
v3: reorganized the patches as per Laine's suggestion. Added more
details in commit messages. Added conf description in formatdomain.rst.
Added changelog for next release.
v2: fixed bugs and added additional missing unit tests.
v1: initial implementation. Had some bugs and missed some unit tests
This change introduces a new libvirt sub-element <pci> under <features> that
can be used to configure all pci related features.
Currently the only sub-sub element supported by this sub-element is
'acpi-bridge-hotplug' as shown below:
<features>
<pci>
<acpi-bridge-hotplug state='on|off'/>
</pci>
</features>
The above option is only available for qemu driver and that too for x86 guests
only. It is a global option.
'acpi-bridge-hotplug' option enables or disables ACPI hotplug support for
cold-plugged pci bridges. Examples of bridges include PCI-PCI bridge
(pci-bridge controller) or PCIe-PCI bridges for pc machines and
pcie-root-port controller for q35 machines. Being global option, no other
bridge specific option are required. For pc machine type in x86, this option
is available in qemu for a long time, from version 2.1.
Please see the following changes in qemu repo:
9e047b982452c6 ("piix4: add acpi pci hotplug support")
133a2da488062e ("pc: acpi: generate AML only for PCI0 devices if PCI bridge hotplug is disabled")
For q35 machine type, this was introduced in qemu 6.1 with the following
changes in qemu repo:
(a) c0e427d6eb5fef ("hw/acpi/ich9: Enable ACPI PCI hot-plug")
(b) 17858a16950860 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35")
The reasons for enabling ACPI based hotplug for PCIe (q35) based machines (as
opposed to native hotplug) are outlined in (b). There are use cases where users
would still want to use native hotplug. Therefore, this config option
enables users to choose either ACPI based hotplug or native hotplug for bridges
(for example for pcie root port controller in q35 machines).
Ani Sinha (4):
qemu: capablities: detect presence of
acpi-pci-hotplug-with-bridge-support
conf: introduce support for acpi-bridge-hotplug feature
qemu: command: add support for acpi-bridge-hotplug feature
NEWS: add new acpi pci hotplug config option in the release note for
next release
NEWS.rst | 7 ++
docs/formatdomain.rst | 11 +++
docs/schemas/domaincommon.rng | 15 ++++
src/conf/domain_conf.c | 89 ++++++++++++++++++-
src/conf/domain_conf.h | 9 ++
src/qemu/qemu_capabilities.c | 6 ++
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_command.c | 14 +++
src/qemu/qemu_validate.c | 46 ++++++++++
.../caps_2.11.0.x86_64.xml | 1 +
.../caps_2.12.0.x86_64.xml | 1 +
.../caps_3.0.0.x86_64.xml | 1 +
.../caps_3.1.0.x86_64.xml | 1 +
.../caps_4.0.0.x86_64.xml | 1 +
.../caps_4.1.0.x86_64.xml | 1 +
.../caps_4.2.0.x86_64.xml | 1 +
.../caps_5.0.0.x86_64.xml | 1 +
.../caps_5.1.0.x86_64.xml | 1 +
.../caps_5.2.0.x86_64.xml | 1 +
.../caps_6.0.0.x86_64.xml | 1 +
.../caps_6.1.0.x86_64.xml | 2 +
.../aarch64-acpi-hotplug-bridge-disable.err | 1 +
.../aarch64-acpi-hotplug-bridge-disable.xml | 33 +++++++
...pc-i440fx-acpi-hotplug-bridge-disable.args | 31 +++++++
.../pc-i440fx-acpi-hotplug-bridge-disable.err | 1 +
.../pc-i440fx-acpi-hotplug-bridge-disable.xml | 33 +++++++
.../pc-i440fx-acpi-hotplug-bridge-enable.xml | 33 +++++++
.../q35-acpi-hotplug-bridge-disable.args | 33 +++++++
.../q35-acpi-hotplug-bridge-disable.err | 1 +
.../q35-acpi-hotplug-bridge-disable.xml | 47 ++++++++++
.../q35-acpi-hotplug-bridge-enable.xml | 47 ++++++++++
tests/qemuxml2argvtest.c | 16 ++++
.../pc-i440fx-acpi-hotplug-bridge-disable.xml | 1 +
.../pc-i440fx-acpi-hotplug-bridge-enable.xml | 1 +
.../q35-acpi-hotplug-bridge-disable.xml | 1 +
.../q35-acpi-hotplug-bridge-enable.xml | 1 +
tests/qemuxml2xmltest.c | 14 +++
37 files changed, 507 insertions(+), 1 deletion(-)
create mode 100644 tests/qemuxml2argvdata/aarch64-acpi-hotplug-bridge-disable.err
create mode 100644 tests/qemuxml2argvdata/aarch64-acpi-hotplug-bridge-disable.xml
create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-disable.args
create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-disable.err
create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-disable.xml
create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-enable.xml
create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.args
create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.err
create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.xml
create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-enable.xml
create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-hotplug-bridge-disable.xml
create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-hotplug-bridge-enable.xml
create mode 120000 tests/qemuxml2xmloutdata/q35-acpi-hotplug-bridge-disable.xml
create mode 120000 tests/qemuxml2xmloutdata/q35-acpi-hotplug-bridge-enable.xml
--
2.25.1
3 years, 2 months
Entering freeze for libvirt-7.8.0
by Jiri Denemark
I have just tagged v7.8.0-rc1 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make sure the issue is more visible.
If you have not done so yet, please update NEWS.rst to document any
significant change you made since the last release.
Thanks,
Jirka
3 years, 2 months
[libvirt PATCH] scripts: include function versions in API definition
by Daniel P. Berrangé
In order to auto-generate more of the language binding code, it is
desirable to know what libvirt version an API was introduced in.
We can extract this information from the .syms files and expose
it in the API description
eg instead of
<function name='virNodeNumOfDevices' file='libvirt-nodedev'
module='libvirt-nodedev'>
we now have
<function name='virNodeNumOfDevices' file='libvirt-nodedev'
module='libvirt-nodedev' version='0.5.0'>
This will benefit this proposal:
https://gitlab.com/libvirt/libvirt-go-module/-/merge_requests/7
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
scripts/apibuild.py | 68 +++++++++++++++++++++++++++++++++++++++++----
1 file changed, 62 insertions(+), 6 deletions(-)
diff --git a/scripts/apibuild.py b/scripts/apibuild.py
index 9b29466e1d..bdd3077c48 100755
--- a/scripts/apibuild.py
+++ b/scripts/apibuild.py
@@ -2030,8 +2030,9 @@ class CParser:
class docBuilder:
"""A documentation builder"""
- def __init__(self, name, path='.', directories=['.'], includes=[]):
+ def __init__(self, name, syms, path='.', directories=['.'], includes=[]):
self.name = name
+ self.syms = syms
self.path = path
self.directories = directories
if name == "libvirt":
@@ -2044,6 +2045,7 @@ class docBuilder:
self.includes = includes + list(admin_included_files.keys())
self.modules = {}
self.headers = {}
+ self.versions = {}
self.idx = index()
self.xref = {}
self.index = {}
@@ -2114,6 +2116,44 @@ class docBuilder:
self.modules[module] = idx
self.idx.merge_public(idx)
+ def scanVersions(self):
+ prefix = self.name.upper().replace("-", "_") + "_"
+
+ version = None
+ prevversion = None
+ with open(self.syms, "r") as syms:
+ while True:
+ line = syms.readline()
+ if not line:
+ break
+ line = line.strip()
+ if line.startswith("#"):
+ continue
+ if line == "":
+ continue
+
+ if line.startswith(prefix) and line.endswith(" {"):
+ version = line[len(prefix):-2]
+ elif line == "global:":
+ continue
+ elif line == "local:":
+ continue
+ elif line.startswith("}"):
+ if prevversion is None:
+ if line != "};":
+ raise Exception("Unexpected closing version")
+ else:
+ if line != ("} %s%s;" % (prefix, prevversion)):
+ raise Exception("Unexpected end of version '%s': %s'" % (line, "} " + prefix + version))
+
+ prevversion = version
+ version = None
+ elif line.endswith(";") and version is not None:
+ func = line[:-1]
+ self.versions[func] = version
+ else:
+ raise Exception("Unexpected line in syms file: %s" % line)
+
def scan(self):
for directory in self.directories:
files = glob.glob(directory + "/*.c")
@@ -2136,6 +2176,7 @@ class docBuilder:
self.headers[file] = None
self.scanHeaders()
self.scanModules()
+ self.scanVersions()
def modulename_file(self, file):
module = os.path.basename(file)
@@ -2275,9 +2316,17 @@ class docBuilder:
print("=>", id)
# NB: this is consumed by a regex in 'getAPIFilenames' in hvsupport.pl
- output.write(" <%s name='%s' file='%s' module='%s'>\n" % (id.type,
- name, self.modulename_file(id.header),
- self.modulename_file(id.module)))
+ if id.type == "function":
+ ver = self.versions[name]
+ if ver is None:
+ raise Exception("Missing version for '%s'" % name)
+ output.write(" <function name='%s' file='%s' module='%s' version='%s'>\n" % (
+ name, self.modulename_file(id.header),
+ self.modulename_file(id.module), self.versions[name]))
+ else:
+ output.write(" <functype name='%s' file='%s' module='%s'>\n" % (
+ name, self.modulename_file(id.header),
+ self.modulename_file(id.module)))
#
# Processing of conditionals modified by Bill 1/1/05
#
@@ -2406,9 +2455,16 @@ class app:
print(msg)
def rebuild(self, name, srcdir, builddir):
- if name not in ["libvirt", "libvirt-qemu", "libvirt-lxc", "libvirt-admin"]:
+ syms = {
+ "libvirt": srcdir + "/../src/libvirt_public.syms",
+ "libvirt-qemu": srcdir + "/../src/libvirt_qemu.syms",
+ "libvirt-lxc": srcdir + "/../src/libvirt_lxc.syms",
+ "libvirt-admin": srcdir + "/../src/admin/libvirt_admin_public.syms",
+ }
+ if name not in syms:
self.warning("rebuild() failed, unknown module %s" % name)
return None
+
builder = None
if glob.glob(srcdir + "/../src/libvirt.c") != []:
if not quiet:
@@ -2418,7 +2474,7 @@ class app:
srcdir + "/../src/util",
srcdir + "/../include/libvirt",
builddir + "/../include/libvirt"]
- builder = docBuilder(name, builddir, dirs, [])
+ builder = docBuilder(name, syms[name], builddir, dirs, [])
else:
self.warning("rebuild() failed, unable to guess the module")
return None
--
2.31.1
3 years, 3 months
[PATCH v6 0/4] Add support to enable/disable hotplug on pci-root controller
by Ani Sinha
changelog:
v6: incorporated Jan's suggestions.
v5: incorporated suggestions from Laine for patches #2 and #3. The qemu command line
is now added in a new function and called from qemuBuildControllersByTypeCommandLine().
Output xmls are now symlinked to input xmls for unit tests.
v4: split the original patchset into a pci-root controller specific patch series.
also the libvirt conf is now a sub-element of the pci-root controller as was
suggested by Dan Berrange. Please see discussion here:
https://listman.redhat.com/archives/libvir-list/2021-September/msg00839.html
v3: reorganized the patches as per Laine's suggestion. Added more
details in commit messages. Added conf description in formatdomain.rst.
Added changelog for next release.
v2: fixed bugs and added additional missing unit tests.
v1: initial implementation. Had some bugs and missed some unit tests
This patchset introduces libvirt xml support to enable/disable hotplug on the
pci-root controller. It adds a 'target' subelement for the pci-root controller
with a 'hotplug' property. This property can be used to enable or disable
hotplug for the pci-root controller. For example, in order to disable hotplug
on the pci-root controller, one has to use set '<target hotplug='off'>' as
shown below:
<controller type='pci' model='pci-root'>
<target hotplug='off'/>
</controller>
'<target hotplug='on'>' option would enable hotplug for pci-root controller.
This is also the default value. This option is only available for pc machine
types and is applicable for qemu only/kvm accelerator onlt.This feature was
introduced from qemu version 5.2 with the following change in qemu repository:
3d7e78aa7777f ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus")
The above qemu commit describes some reasons why users might to disable hotplug
on PCI root buses [1].
The corresponding commandline option to qemu for x86 guests is:
-global PIIX4_PM.acpi-root-pci-hotplug=<off/on>
Notes:
1. The use case scenario described by Laine in
https://listman.redhat.com/archives/libvir-list/2020-February/msg00110.html
intentionally does not discuss i440fx and focusses solely on q35. I do realize
that redhat has moved on from i440fx and currently efforts for new features
are concentrated on q35 machines only. We have had some hard debates on this
on the qemu mailing list before. The fact of the matter is that i440fx is
not at 1-1 parity with q35. There are many users who are currenly using i440fx
and are simply not ready to move to q35 without sacrificing some
existing features they support today. For example
https://wiki.qemu.org/images/4/4e/Q35.pdf lists some of q35 limitations.
https://www.linux-kvm.org/images/0/06/2012-forum-Q35.pdf provides more
information on the differences. Hence we need to solve the issue Laine has
described in the above email for i440fx without adding additional bridges.
Further, in Daniel Berrange's words from :
https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg03012.html
"From the upstream POV, there's been no decision / agreement to phase
out PIIX, this is purely a RHEL downstream decision & plan. If other
distros / users have a different POV, and find the feature useful, we
should accept the patch if it meets the normal QEMU patch requirements.
"
Also to be noted that I have already experimented this qemu commandline option
using libvirt passthrough feature as has been documented in
http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html
This was only meant to be a short term solution until libvirt started
supporting this natively. Supporting this option through libvirt would simplify
their use case as well as add capability validations
and graceful failure scenarios in case qemu did not support the option.
Ani Sinha (4):
qemu: capablities: detect presence of acpi-root-pci-hotplug for i440fx
machines
conf: introduce option to enable/disable pci hotplug on pci-root
controller
qemu: command: add support to enable/disable hotplug on pci-root
controller
NEWS: release note the new hotplug enable/disable option on pci-root
controller
NEWS.rst | 6 ++++
docs/formatdomain.rst | 12 ++++---
src/qemu/qemu_capabilities.c | 4 +++
src/qemu/qemu_capabilities.h | 3 ++
src/qemu/qemu_command.c | 17 ++++++++++
src/qemu/qemu_validate.c | 9 +++++-
.../caps_5.2.0.x86_64.xml | 1 +
.../caps_6.0.0.x86_64.xml | 1 +
.../caps_6.1.0.x86_64.xml | 1 +
.../pc-i440fx-acpi-root-hotplug-disable.args | 31 +++++++++++++++++++
.../pc-i440fx-acpi-root-hotplug-disable.err | 1 +
.../pc-i440fx-acpi-root-hotplug-disable.xml | 30 ++++++++++++++++++
.../pc-i440fx-acpi-root-hotplug-enable.xml | 30 ++++++++++++++++++
tests/qemuxml2argvtest.c | 3 ++
.../pc-i440fx-acpi-root-hotplug-disable.xml | 1 +
.../pc-i440fx-acpi-root-hotplug-enable.xml | 1 +
tests/qemuxml2xmltest.c | 4 +++
17 files changed, 149 insertions(+), 6 deletions(-)
create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.args
create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.err
create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.xml
create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-enable.xml
create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-root-hotplug-disable.xml
create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-root-hotplug-enable.xml
--
2.25.1
3 years, 3 months
[libvirt PATCH] vshCmddefCheckInternals: Fix typo
by Tim Wiederhake
Signed-off-by: Tim Wiederhake <twiederh(a)redhat.com>
---
tools/vsh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/vsh.c b/tools/vsh.c
index 189c452f73..7b77acad34 100644
--- a/tools/vsh.c
+++ b/tools/vsh.c
@@ -279,7 +279,7 @@ vshCmddefCheckInternals(vshControl *ctl,
}
if (!(alias = vshCmddefSearch(cmd->alias))) {
- vshError(ctl, _("command alias '%s' is pointing to a non-existant command '%s'"),
+ vshError(ctl, _("command alias '%s' is pointing to a non-existent command '%s'"),
cmd->name, cmd->alias);
return -1;
}
--
2.31.1
3 years, 3 months
[PATCH v5 0/4] Add support to enable/disable hotplug on pci-root controller
by Ani Sinha
changelog:
v5: incorporated suggestions from Laine for patches #2 and #3. The qemu command line
is now added in a new function and called from qemuBuildControllersByTypeCommandLine().
Output xmls are now symlinked to input xmls for unit tests.
v4: split the original patchset into a pci-root controller specific patch series.
also the libvirt conf is now a sub-element of the pci-root controller as was
suggested by Dan Berrange. Please see discussion here:
https://listman.redhat.com/archives/libvir-list/2021-September/msg00839.html
v3: reorganized the patches as per Laine's suggestion. Added more
details in commit messages. Added conf description in formatdomain.rst.
Added changelog for next release.
v2: fixed bugs and added additional missing unit tests.
v1: initial implementation. Had some bugs and missed some unit tests
This patchset introduces libvirt xml support to enable/disable hotplug on the
pci-root controller. It adds a 'target' subelement for the pci-root controller
with a 'hotplug' property. This property can be used to enable or disable
hotplug for the pci-root controller. For example, in order to disable hotplug
on the pci-root controller, one has to use set '<target hotplug='off'>' as
shown below:
<controller type='pci' model='pci-root'>
<target hotplug='off'/>
</controller>
'<target hotplug='on'>' option would enable hotplug for pci-root controller.
This is also the default value. This option is only available for pc machine
types and is applicable for qemu only/kvm accelerator onlt.This feature was
introduced from qemu version 5.2 with the following change in qemu repository:
3d7e78aa7777f ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus")
The above qemu commit describes some reasons why users might to disable hotplug
on PCI root buses [1].
The corresponding commandline option to qemu for x86 guests is:
-global PIIX4_PM.acpi-root-pci-hotplug=<off/on>
Notes:
1. The use case scenario described by Laine in
https://listman.redhat.com/archives/libvir-list/2020-February/msg00110.html
intentionally does not discuss i440fx and focusses solely on q35. I do realize
that redhat has moved on from i440fx and currently efforts for new features
are concentrated on q35 machines only. We have had some hard debates on this
on the qemu mailing list before. The fact of the matter is that i440fx is
not at 1-1 parity with q35. There are many users who are currenly using i440fx
and are simply not ready to move to q35 without sacrificing some
existing features they support today. For example
https://wiki.qemu.org/images/4/4e/Q35.pdf lists some of q35 limitations.
https://www.linux-kvm.org/images/0/06/2012-forum-Q35.pdf provides more
information on the differences. Hence we need to solve the issue Laine has
described in the above email for i440fx without adding additional bridges.
Further, in Daniel Berrange's words from :
https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg03012.html
"From the upstream POV, there's been no decision / agreement to phase
out PIIX, this is purely a RHEL downstream decision & plan. If other
distros / users have a different POV, and find the feature useful, we
should accept the patch if it meets the normal QEMU patch requirements.
"
Also to be noted that I have already experimented this qemu commandline option
using libvirt passthrough feature as has been documented in
http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html
This was only meant to be a short term solution until libvirt started
supporting this natively. Supporting this option through libvirt would simplify
their use case as well as add capability validations
and graceful failure scenarios in case qemu did not support the option.
Ani Sinha (4):
qemu: capablities: detect presence of acpi-root-pci-hotplug for i440fx
machines
conf: introduce option to enable/disable pci hotplug on pci-root
controller
qemu: command: add support to enable/disable hotplug on pci-root
controller
NEWS: release note the new hotplug enable/disable option on pci-root
controller
NEWS.rst | 6 ++++
docs/formatdomain.rst | 12 ++++---
src/qemu/qemu_capabilities.c | 4 +++
src/qemu/qemu_capabilities.h | 3 ++
src/qemu/qemu_command.c | 17 ++++++++++
src/qemu/qemu_validate.c | 9 +++++-
.../caps_5.2.0.x86_64.xml | 1 +
.../caps_6.0.0.x86_64.xml | 1 +
.../caps_6.1.0.x86_64.xml | 1 +
.../pc-i440fx-acpi-root-hotplug-disable.args | 31 +++++++++++++++++++
.../pc-i440fx-acpi-root-hotplug-disable.err | 1 +
.../pc-i440fx-acpi-root-hotplug-disable.xml | 30 ++++++++++++++++++
.../pc-i440fx-acpi-root-hotplug-enable.xml | 30 ++++++++++++++++++
tests/qemuxml2argvtest.c | 3 ++
.../pc-i440fx-acpi-root-hotplug-disable.xml | 1 +
.../pc-i440fx-acpi-root-hotplug-enable.xml | 1 +
tests/qemuxml2xmltest.c | 4 +++
17 files changed, 149 insertions(+), 6 deletions(-)
create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.args
create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.err
create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.xml
create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-enable.xml
create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-root-hotplug-disable.xml
create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-root-hotplug-enable.xml
--
2.25.1
3 years, 3 months
