Commit Graph

43509 Commits

Author SHA1 Message Date
Michal Privoznik
51f65e9522 qemu: Account for both memballoon and virtio-mem
Reporting how much memory is exposed to the guest happens under
<currentMemory/> which is taken from def->mem.cur_balloon. The
reported amount should account for both balloon size and the sum
of @currentsize of all virtio-mems. For instance, if domain has
4GiB via balloon and additional 2GiB via virtio-mem, then the
domain XML should report 6GiB. The same applies for domain
statistics.

The way to achieve this is to account for either balloon or
virtio-mem when the size of the other is changed, e.g. on balloon
change we have to add all @currentsize (for non virtio-mem these
will be zero, so the check for memory model is needless, but
makes it more obvious what's happening), and vice versa.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-10-01 11:04:57 +02:00
Michal Privoznik
5c2d6908a6 qemu: Refresh the current size of virtio-mem on monitor reconnect
If the QEMU driver restarts it loses the track of the current size
of virtio-mem (because it's runtime type of information and thus
not stored in XML) and therefore, we have to refresh it when
reconnecting to the domain monitor.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-10-01 11:04:53 +02:00
Michal Privoznik
9985f62b51 qemu: Wire up MEMORY_DEVICE_SIZE_CHANGE event
As advertised in previous commit, this event is delivered to us
when virtio-mem module changes the allocation inside the guest.
It comes with one attribute - size - which holds the new size of
the virtio-mem (well, allocated size), in bytes.
Mind you, this is not necessarily the same number as 'requested
size'. It almost certainly will be when sizing the memory up, but
it might not be when sizing the memory down - the guest kernel
might be unable to free some blocks.

This current size is reported in the domain XML as an output
element only.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-10-01 11:04:47 +02:00
Michal Privoznik
dcd9f8e2c5 conf: Introduce virDomainMemoryFindByDeviceAlias()
This function will be needed in the next commit where we will
want to find virtio-mem given its alias by QEMU on the monitor.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-10-01 11:04:29 +02:00
Michal Privoznik
59e9fb98f5 Introduce <current/> property to virtio-mem
The virtio-mem has another property that isn't exposed yet:
current size exposed to the guest. Please note, that this is
different to <requested/> because esp. on sizing the memory
down guest may refuse to release some blocks. Therefore, let's
have another size to report in the XML. But because of its
nature, the <current/> won't be parsed and is report only (for
live XMLs).

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-10-01 11:04:25 +02:00
Michal Privoznik
99e4ae2b02 qemu: Wire up <memory/> offline update
Updating offline XML of <memory/> devices might come handy when
dealing with virtio-mem devices. But it's implemented to just
replace one virDomainMemoryDef with another so it can be used to
change almost anything.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-10-01 11:04:21 +02:00
Michal Privoznik
3ec559661a qemu: Wire up <memory/> live update
As advertised in one of previous commits, we want to be able to
change 'requested-size' attribute of virtio-mem on the fly. This
commit does exactly that. Changing anything else is checked for
and forbidden.

Once guest has changed the allocation, QEMU emits an event which
we will use to track the allocation. In the next commit.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-10-01 11:04:16 +02:00
Michal Privoznik
363866a1e2 qemu: Build command line for virtio-mem
Nothing special is happening here. All important changes were
done when for 'virtio-pmem' (adjusting the code to put virtio
memory on PCI bus, generating alias using
qemuDomainDeviceAliasIndex(). The only bit that might look
suspicious is no prealloc for virtio-mem. But if you think about
it, the whole purpose of this device is to change amount of
memory exposed to guest on the fly. There is no point in locking
the whole backend in memory.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-10-01 11:04:05 +02:00
Michal Privoznik
f931cb7f21 conf: Introduce virtio-mem <memory/> model
The virtio-mem is paravirtualized mechanism of adding/removing
memory to/from a VM. A virtio-mem-pci device is split into blocks
of equal size which are then exposed (all or only a requested
portion of them) to the guest kernel to use as regular memory.
Therefore, the device has two important attributes:

  1) block-size, which defines the size of a block
  2) requested-size, which defines how much memory (in bytes)
     is the device requested to expose to the guest.

The 'block-size' is configured on command line and immutable
throughout device's lifetime. The 'requested-size' can be set on
the command line too, but also is adjustable via monitor. In
fact, that is how management software places its requests to
change the memory allocation. If it wants to give more memory to
the guest it changes 'requested-size' to a bigger value, and if it
wants to shrink guest memory it changes the 'requested-size' to a
smaller value. Note, value of zero means that guest should
release all memory offered by the device. Of course, guest has to
cooperate. Therefore, there is a third attribute 'size' which is
read only and reflects how much memory the guest still has. This
can be different to 'requested-size', obviously. Because of name
clash, I've named it 'current' and it is dealt with in future
commits (it is a runtime information anyway).

In the backend, memory for virtio-mem is backed by usual objects:
memory-backend-{ram,file,memfd} and their size puts the cap on
the amount of memory that a virtio-mem device can offer to a
guest. But we are already able to express this info using <size/>
under <target/>.

Therefore, we need only two more elements to cover 'block-size'
and 'requested-size' attributes. This is the XML I've came up
with:

  <memory model='virtio-mem'>
    <source>
      <nodemask>1-3</nodemask>
      <pagesize unit='KiB'>2048</pagesize>
    </source>
    <target>
      <size unit='KiB'>2097152</size>
      <node>0</node>
      <block unit='KiB'>2048</block>
      <requested unit='KiB'>1048576</requested>
    </target>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
  </memory>

I hope by now it is obvious that:

  1) 'requested-size' must be an integer multiple of
     'block-size', and
  2) virtio-mem-pci device goes onto PCI bus and thus needs PCI
     address.

Then there is a limitation that the minimal 'block-size' is
transparent huge page size (I'll leave this without explanation).

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-10-01 11:02:53 +02:00
Michal Privoznik
ed7c51b42e qemu_capabilities: Introduce QEMU_CAPS_MEMORY_BACKEND_RESERVE
This capability tracks whether memory-backend-* supports .reserve
attribute which is going to be important for backends associated
with virtio-mem devices.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-10-01 11:02:09 +02:00
Michal Privoznik
284d9c46d7 qemu_capabilities: Introduce QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI
This commit introduces a new capability that reflects virtio-mem-pci
device support in QEMU:

  QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI, /* -device virtio-mem-pci */

The virtio-mem-pci device was introduced in QEMU 5.1.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-10-01 11:01:32 +02:00
Michal Privoznik
45aa4c1d2a virhostmem: Introduce virHostMemGetTHPSize()
New virHostMemGetTHPSize() is introduced which allows caller to
obtain THP PMD (Page Middle Directory) size, which is equal to
the minimal size that THP can use, taken from kernel doc
(Documentation/admin-guide/mm/transhuge.rst):

  Some userspace (such as a test program, or an optimized memory allocation
  library) may want to know the size (in bytes) of a transparent hugepage::

    cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size

Since this size depends on the host architecture and the kernel
it won't change whilst libvirtd is running. Therefore, we can use
virOnce() and cache the value. Of course, we can be running under
kernel that has THP disabled or has no notion of THP at all. In
that case a negative value is returned to signal error.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-10-01 10:58:27 +02:00
Michal Privoznik
9c47d2754c qemuBuildNumaCommandLine: Separate out building of CPU list
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-10-01 10:52:35 +02:00
Michal Privoznik
c9f47bfc7a qemuBuildNumaCommandLine: Move vars into loops
There are two variables that are used only in a single
loop. Move their definitions into their respective blocks.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-10-01 10:52:35 +02:00
Michal Privoznik
c7d7cae5cc virCPUDefParseXML: Prefer virXMLPropUInt over virXPathUInt
When parsing CPU topology, which is described in <topology/>
attributes we can use virXMLPropUInt() instead of virXPathUInt()
as the former results in shorter code.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-10-01 10:52:35 +02:00
Michal Privoznik
97fbb7e7e8 virCPUDefParseXML: Parse uint using virXPathUInt()
There is no need to use virXPathULong() and a temporary UL
variable if we can use virXPathUInt() directly.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-10-01 10:52:35 +02:00
Jiri Denemark
e2999909fc Post-release version bump to 7.9.0
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2021-10-01 10:38:45 +02:00
Jiri Denemark
1bb38487f9 Release of libvirt-7.8.0
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2021-10-01 10:34:54 +02:00
Yuri Chornoivan
f0580a9301 Translated using Weblate (Ukrainian)
Currently translated at 100.0% (10374 of 10374 strings)

Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/uk/

Co-authored-by: Yuri Chornoivan <yurchor@ukr.net>
Signed-off-by: Yuri Chornoivan <yurchor@ukr.net>
2021-09-29 10:05:11 +02:00
Piotr Drąg
d08ce05b57 Translated using Weblate (Polish)
Currently translated at 22.6% (2345 of 10374 strings)

Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/pl/

Co-authored-by: Piotr Drąg <piotrdrag@gmail.com>
Signed-off-by: Piotr Drąg <piotrdrag@gmail.com>
2021-09-29 10:05:10 +02:00
simmon
5c1be90b61 Translated using Weblate (Korean)
Currently translated at 99.7% (10345 of 10374 strings)

Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/ko/

Co-authored-by: simmon <simmon@nplob.com>
Signed-off-by: simmon <simmon@nplob.com>
2021-09-29 10:05:10 +02:00
Weblate
e37605f9a9 Update translation files
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.

Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/

Co-authored-by: Weblate <noreply@weblate.org>
Signed-off-by: Fedora Weblate Translation <i18n@lists.fedoraproject.org>
2021-09-29 10:05:07 +02:00
Jiri Denemark
65499b4f09 po: Refresh potfile for v7.8.0
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2021-09-27 11:38:35 +02:00
simmon
81367cd476 Translated using Weblate (Korean)
Currently translated at 100.0% (10353 of 10353 strings)

Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/ko/

Co-authored-by: simmon <simmon@nplob.com>
Signed-off-by: simmon <simmon@nplob.com>
2021-09-27 10:12:26 +02:00
jason lee
acb3c2d843 Translated using Weblate (Korean)
Currently translated at 100.0% (10353 of 10353 strings)

Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/ko/

Co-authored-by: jason lee <ppark5237@gmail.com>
Signed-off-by: jason lee <ppark5237@gmail.com>
2021-09-27 10:12:26 +02:00
simmon
ecf7022d98 Translated using Weblate (Korean)
Currently translated at 100.0% (10353 of 10353 strings)

Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/ko/

Translated using Weblate (Korean)

Currently translated at 92.4% (9576 of 10353 strings)

Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/ko/

Co-authored-by: simmon <simmon@nplob.com>
Signed-off-by: simmon <simmon@nplob.com>
2021-09-27 10:12:26 +02:00
jason lee
b4345be7c0 Translated using Weblate (Korean)
Currently translated at 92.4% (9576 of 10353 strings)

Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/ko/

Translated using Weblate (Korean)

Currently translated at 91.6% (9484 of 10353 strings)

Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/ko/

Co-authored-by: jason lee <ppark5237@gmail.com>
Signed-off-by: jason lee <ppark5237@gmail.com>
2021-09-27 10:12:26 +02:00
Ján Tomko
0522f02f35 qemu: deprecate QEMU_CAPS_FSDEV_CREATEMODE
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-27 10:11:22 +02:00
Ján Tomko
43fac71b70 qemu: assume QEMU_CAPS_FSDEV_CREATEMODE
Added by QEMU commit:
b96feb2cb9 "9pfs: local: Add support for custom fmode/dmode in 9ps
mapped security modes"
in 2.10.0

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-27 10:11:22 +02:00
Ján Tomko
f501cec73d qemu: Deprecate QEMU_CAPS_MACHINE_KERNEL_IRQCHIP
Now that it's no longer used, remove probing for it
and mark it as deprecated.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-27 10:11:22 +02:00
Ján Tomko
7cd2e25991 qemu: assume QEMU_CAPS_MACHINE_KERNEL_IRQCHIP
Even though we only allow this option on x86,
all QEMUs report the command line option.

Added in QEMU v1.1:
6a48ffaaa7 "kvm: Activate in-kernel irqchip support"

Remove the pointless capability.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-27 10:11:21 +02:00
Ján Tomko
c0f82ba205 qemu: capabilities: do not look at parameters for sandbox
Assume the presence of the 'sandbox' option is enough,
no need to look at the parameters.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-27 10:11:21 +02:00
Ján Tomko
3f3cf5899c qemu: capabilities: deprecate QEMU_CAPS_SECCOMP_BLACKLIST
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-27 10:11:21 +02:00
Ján Tomko
cfb8951e68 qemu: seccomp: remove dead code
There is no QEMU we support that would need the old syntax
for -sandbox on.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-27 10:11:21 +02:00
Ján Tomko
d1be5aa6a4 qemu: conf: simplify seccomp_sandbox comment
It contains too many negations and conditions that are
no longer relevant now that we only support QEMU >= 2.11.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-27 10:11:21 +02:00
Ján Tomko
142938f5c2 qemu: always assume QEMU_CAPS_SECCOMP_BLACKLIST
elevateprivileges was introduced by QEMU commit:
73a1e64725 "seccomp: add elevateprivileges argument to command line"
released in 2.11.0
and later made conditional on SECCOMP support by:
9d0fdecbad sandbox: disable -sandbox if CONFIG_SECCOMP undefined

Use the existence of the sandbox option as a witness for its support.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-27 10:11:21 +02:00
Zhenzhong Duan
88a3977922 qemu: ingore the transient domain state in fake reboot
When action for 'on_poweroff' is set to 'restart', 'fake reboot'
is triggered and qemu shutdown state is transient. Domain state
need not to be changed and events not sent in this case.

Fixes: 4ffc807214
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-27 09:53:20 +02:00
Kristina Hanicova
49d74124a5 virsh: domain: remove else branch
I removed else branches after return/break as they are not
necessary and the code looks cleaner without them.

Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-25 09:30:53 +02:00
Kristina Hanicova
bd82e3d81a virsh: domain: remove 'ret' variable and use 'count' instead
This patch also includes use of an early return in case of an
error. I think the changes make the functions more readable.

Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-25 09:30:43 +02:00
Kristina Hanicova
24ddb0cdfe virsh: domain: use early return when possible
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-25 09:30:09 +02:00
Kristina Hanicova
6e1cdf928c virsh: domain: remove 'ret' variable, use early return when possible
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-25 09:28:51 +02:00
Kristina Hanicova
9a5db04fe6 virsh: domain: remove 'ret' variable and use direct return when possible
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-25 09:28:45 +02:00
Kristina Hanicova
a1fe822801 virsh: domain: remove nested 'if' in cmdAttachDisk()
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-25 09:27:34 +02:00
Kristina Hanicova
14a804ee67 virsh: domain: use early return in virshDomainDefine()
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-25 09:25:56 +02:00
Kristina Hanicova
bc7b8a34fa virsh: domain: remove unnecessary variable and label in cmdMigrateSetMaxDowntime()
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-25 09:16:30 +02:00
Kristina Hanicova
0987edbedf virsh: domain: fix mistake in cmdMigrateSetMaxDowntime()
If there was added a new return value indicating success to the
function virDomainMigrateSetMaxDowntime() in the future, because
of the way the function is called it would be treated it as an
error state and would return false (indicating failure). This
patch fixes it, so that the call of the function follows the same
pattern as is currently set in libvirt.

Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-25 09:14:56 +02:00
Tim Wiederhake
7c98320278 meson: Increase stack size limit for sanitizer builds
When building with "CC=clang", "-Db_sanitize=address,undefined", and
"-Dbuildtype=debug", the following error occurs:

    ../src/conf/nwfilter_conf.c:2190:1: error: stack frame size of 10616
    bytes in function 'virNWFilterRuleDefFixup' [-Werror,-Wframe-larger-than=]
    virNWFilterRuleDefFixup(virNWFilterRuleDef *rule)
    ^
    1 error generated.

Enforcing stack frame only makes sense on normal builds when stack usage
is deterministic.

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-09-24 16:37:06 +02:00
Michal Privoznik
bf9074c6a8 vsh: Don't check for OOM in vshGetTypedParamValue()
Both function description and function itself mention check for
OOM which can't happen really. There was a bug in glib where
g_strdup_*() might have not aborted on OOM, but we have our own
implementation when dealing with broken glib (see
vir_g_strdup_printf()). Therefore, checking for OOM is redundant
and can never be true.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-09-24 12:40:48 +02:00
Erik Skultety
40f5c8679a libvirt.spec.in: Replace %global with %define
Commit b5e8db8f14 tuned the SPEC file so that libvirt daemons restart
on package upgrade. In order to do that it added a bunch of
parametrized macros using the %global directive. This caused a problem
when running RPM builds on CentOS Stream 8 resulting in:

error: Too many levels of recursion in macro expansion. It is likely
       caused by recursive macro declaration.
error: Macro %libvirt_daemon_perform_restart failed to expand
error: line 1275: %global libvirt_daemon_perform_restart() \
       if test %libvirt_daemon_needs_restart %1 \
       then \
           /bin/systemctl try-restart %1.service >/dev/null 2>&1 || : \
       fi \
       %libvirt_daemon_finish_restart %1

There are 2 important differences between %global and %define
directives:
1) %define is local-only and does have scope - in reality though, its
   scope is apparently not really enforced because it behaves exactly
   the same way as %global
2) %define is evaluated at the time of use while %global is evaluated
   at the time of definition

The latter and the fact the macro is parametrized is the reason why the
RPM builds fails on CentOS. Strangely enough this only happens on
CentOS Stream, but not Fedora (which is also the main proponent of
replacing %define with %global). Anyhow, replacing %global with %define
makes the rpmbuild to pass on both and along with package upgrades.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-09-24 11:01:07 +02:00
Peter Krempa
960ec985a2 qemu: capabilities: Retire QEMU_CAPS_SPICE_FILE_XFER_DISABLE
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-09-24 10:37:01 +02:00