Commit Graph

47051 Commits

Author SHA1 Message Date
Michal Privoznik
ed8696549d qemu: Assume QEMU_CAPS_VIRTIO_NET_TX_QUEUE_SIZE
Introduced in QEMU's commit of v2.10.0-rc0~95^2~20 the
.tx_queue_size attribute of virtio-net device is always available
for all QEMU versions we support (4.2.0, currently). Therefore,
we can assume the capability is always set and thus doesn't need
to be checked for.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
1afab9d245 qemu: Retire QEMU_CAPS_VIRTIO_NET_RX_QUEUE_SIZE
Now that nothing uses this capability, it can be retired.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
5bb7fe5437 qemu_capabilities: Stop detecting QEMU_CAPS_VIRTIO_NET_RX_QUEUE_SIZE
All supported QEMUs have this capability. Stop detecting it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
7fd8465187 qemu: Assume QEMU_CAPS_VIRTIO_NET_RX_QUEUE_SIZE
Introduced in QEMU's commit of v2.8.0-rc0~116^2~26 the
.rx_queue_size attribute of virtio-net device is always available
for all QEMU versions we support (4.2.0, currently). Therefore,
we can assume the capability is always set and thus doesn't need
to be checked for.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
4a7ec2b8d4 qemu: Retire QEMU_CAPS_QUERY_DISPLAY_OPTIONS
Now that nothing uses this capability, it can be retired.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
f02190dc54 qemu_capabilities: Stop detecting QEMU_CAPS_QUERY_DISPLAY_OPTIONS
All supported QEMUs have this capability. Stop detecting it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
b9f70ae05b qemu: Assume QEMU_CAPS_QUERY_DISPLAY_OPTIONS
Introduced in QEMU's commit of v3.1.0-rc3~8^2 the
query-display-options command is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
6e3e008f6e qemu: Retire QEMU_CAPS_BITMAP_MERGE
Now that nothing uses this capability, it can be retired.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
7a69622cf3 qemu_capabilities: Stop detecting QEMU_CAPS_BITMAP_MERGE
All supported QEMUs have this capability. Stop detecting it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
e42461231f qemu: Retire QEMU_CAPS_QUERY_CURRENT_MACHINE
Now that nothing uses this capability, it can be retired.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
55ff57dbf2 qemu_capabilities: Stop detecting QEMU_CAPS_QUERY_CURRENT_MACHINE
All supported QEMUs have this capability. Stop detecting it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
80a5dbb478 qemu: Assume QEMU_CAPS_QUERY_CURRENT_MACHINE
Introduced in QEMU's commit of v4.0.0-rc0~202^2~3 the
query-current-machine command is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
cf54743277 qemu: Retire QEMU_CAPS_QOM_LIST_PROPERTIES
Now that nothing uses this capability, it can be retired.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
b15e602278 qemu_capabilities: Stop detecting QEMU_CAPS_QOM_LIST_PROPERTIES
All supported QEMUs have this capability. Stop detecting it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
3c2697b54c qemu: Assume QEMU_CAPS_QOM_LIST_PROPERTIES
Introduced in QEMU's commit of v2.12.0-rc0~48^2~25 the
qom-list-properties command is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
15919f5558 qemu: Retire QEMU_CAPS_DUMP_COMPLETED
Now that nothing uses this capability, it can be retired.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
45d0015d86 qemu_capabilities: Stop detecting QEMU_CAPS_DUMP_COMPLETED
All supported QEMUs have this capability. Stop detecting it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
ac02c09dd8 qemu: Assume QEMU_CAPS_DUMP_COMPLETED
Introduced in QEMU's commit of v2.6.0-rc0~74^2~6 the
DUMP_COMPLETED event is always available for all QEMU versions we
support (4.2.0, currently). Therefore, we can assume the
capability is always set and thus doesn't need to be checked for.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
5724035ed5 qemu: Retire QEMU_CAPS_VSERPORT_CHANGE
Now that nothing uses this capability, it can be retired.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
bf140a6edd qemu_capabilities: Stop detecting QEMU_CAPS_VSERPORT_CHANGE
All supported QEMUs have this capability. Stop detecting it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
c18e2fd746 qemu_agent: Drop @singleSync from _qemuAgent
Historically, before sending any guest agent command we would
send 'guest-sync' command to make guest agent reset its internal
state and flush any partially read command (json). This was
because there was no event emitted when the agent
(dis-)connected.

But now that we have the event we can execute the sync command
just once - the first time after we've connected. Should agent
disconnect in the middle of reading a command, and then connect
back again we would get the event and disconnect and connect back
again, resulting in the sync command being executed again.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
3cf0a764cd qemu: Assume QEMU_CAPS_VSERPORT_CHANGE
Introduced in QEMU's commit of v2.1.0-rc0~18^2~2 the
VSERPORT_CHANGE event is always available for all QEMU versions
we support (4.2.0, currently). Therefore, we can assume the
capability is always set and thus doesn't need to be checked for.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
05aa2e1a5d qemu: Retire QEMU_CAPS_NUMA
Now that nothing uses this capability, it can be retired.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
8ffcafe211 qemu_capabilities: Stop detecting QEMU_CAPS_NUMA
All supported QEMUs have this capability. Stop detecting it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
8bf50fa018 qemu: Assume QEMU_CAPS_NUMA
Introduced in QEMU's commit of v3.0.0-rc0~124^2~1 the
set-numa-node command is always available for all QEMU versions
we support (4.2.0, currently). Therefore, we can assume the
capability is always set and thus doesn't need to be checked for.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
bb5bc36792 tests: Make qemuAgent single sync
The qemuAgent has option to issue guest-sync command before each
intended command or issue the sync commend just once, right after
the socket is opened and before the first intended command is
issued. The latter is referred to as single sync agent and is
enabled by VSERPORT_CHANGED event which allows us to detect
when the agent (dis-)connects in the guest.

Now, every QEMU that we support (4.2.0 or newer) has the event
and thus will use single sync agent. Therefore, adjust
qemuagenttest to make it test what's used in the real world,
rather than old approach.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
b697b702ac qemu: Acquire QUERY job in qemuDomainQueryWakeupSuspendSupport()
The qemuDomainQueryWakeupSuspendSupport() does not change state
of the domain as it just runs 'query-current-machine' QMP
command. Therefore, there's no need for it to acquire MODIFY job,
QUERY job is perfectly okay.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Michal Privoznik
8d175cbe64 qemu: Drop misleading comment for qemuDomainQueryWakeupSuspendSupport()
The was an attempt to document the retvals for
qemuDomainQueryWakeupSuspendSupport(). However, it's misleading
because in reality, the function can return nothing but 0 or -1,
but the comment implies retval of 1 too.

Since the set of possible return values complies with our
unwritten rule (0 for success, -1 for error), there's no real
value in having the comment and as such can be dropped.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 12:10:50 +01:00
Jiri Denemark
9995ff1352 spec: libvirt-daemon: Add optional dependency on *-client
The libvirt-daemon subpackage contains libvirt-guests.sh script (used by
libvirt-guests service), which requires virsh to actually work. But
since dynamic libraries were separated from libvirt-client to
libvirt-libs more than 6 years ago, libvirt-daemon no longer requires
virsh to be installed. So unless libvirt-client is explicitly installed
(either manually or by installing the libvirt meta package),
libvirt-guests will not work.

Just adding libvirt-client as a dependency of libvirt-daemon would go
against the original idea behind splitting libvirt-client: users may not
want to install or use any client binaries on the host where the daemon
runs (either they just use various language bindings or access the
daemon remotely). To solve this we could possibly turn libvirt-daemon
into an empty package and separate the daemons and libvirt-guests into
subpackages to make sure we support both use cases, but marking
libvirt-client as Recommended for libvirt-daemon does the same job in a
much simpler way.

https://bugzilla.redhat.com/show_bug.cgi?id=2136591

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2022-11-08 10:35:18 +01:00
Lin Yang
5e46d6ec4e conf: Allow > UINT_MAX of cache for NUMA nodes
The high-bandwidth memory (HBM) in cache mode might be greater than
UINT_MAX of cache per NUMA node, so change to unsigned long long.

Signed-off-by: Lin Yang <lin.a.yang@intel.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-11-08 09:49:43 +01:00
Michal Privoznik
91ef81a378 qemu_agent: Bring back single sync
Historically, we had no idea whether the qemu-ga running inside
the guest was running or not. Or whether it crashed in the middle
of reading of a command. That's why we issued guest-sync prior
any intended command, to make the agent flush any partially read
JSON and reset its state machine.

But with VSERPORT_CHANGE event we know when the guest agent
(dis-)connects and thus can issue the sync command just once for
each 'connection'. Whether the agent is synced is tracked in
agent->inSync member, which used to be set to true upon
successful sync. But after rework in v8.0.0-rc1~361 that line is
gone, leaving us with using the historic approach basically.

Fixes: cad84fd51e
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-08 09:17:48 +01:00
Michal Privoznik
d649faddb3 tests: Drop needless .err files from qemuxml2argvdata/
As some qemxml2argvtest cases were removed, we forgot to remove
their expected output counterparts.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-07 18:25:57 +01:00
Peter Krempa
f8ebb58163 conf: schemas: Include 'privatedata.rng' in installed schema files
The privatedata.rng file was accidentally left uninstalled, but it's
referenced by other schema files effectively breaking validation of XMLs
in new installations.

Change to libvirt.spec is not needed as we include all installed schemas
via a wildcard.

Fixes: d8ceacdc87
Reported-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2022-11-07 12:51:48 +01:00
Jakub Kuczys
1dd30e2e22
docs: fix location of :since: 8.1.0 to apply to isa-debugcon
Signed-off-by: Jakub Kuczys <me@jacken.men>
2022-11-06 06:50:46 +01:00
Eric Garver
7f7a09a2d2 network: allow incoming connections to guests on routed networks w/firewalld
Prior to firewalld version 1.0.0, the default action of ACCEPT in the
"libvirt" zone (subsequently overridden with a lower priority "REJECT"
action) would result in an implicit rule that allowed incoming sessions
through the zone; libvirt relied on this implicit rule to permit
incoming connections to guests that were connected via a libvirt
"routed" network.

Starting in firewalld 1.0.0, the rules generated for this same
zonefile changed such that incoming sessions through the libvirt zone
were no longer allowed, breaking the longstanding convention that they
should be allowed (only for routed networks).

However, beginning with firewalld 0.9.0, a zone can explicitly
allow/block forwarded traffic (by adding a "policy" to the zone that
specifies what happens to packets that are going in one zone and out
another zone).

This patch changes the zone for routed networks from "libvirt" to the
newly-added "libvirt-routed" zone that uses the new policy
functionality to once again allow incoming sessions to guests on
routed networks.

(If firewalld is < 0.9.0, then the policy file won't be read at all,
so firewalld won't log any error, and libvirt will just use the old
setup that takes advantage of the implicit forwarding rules).

Resolves: https://bugzilla.redhat.com/2055706
Signed-off-by: Eric Garver <eric@garver.life>
Reviewed-by: Laine Stump <laine@redhat.com>
2022-11-05 14:46:19 -04:00
Eric Garver
2a461957b1 network: firewalld: add policies for routed networks
Signed-off-by: Eric Garver <eric@garver.life>
Reviewed-by: Laine Stump <laine@redhat.com>
2022-11-05 14:40:26 -04:00
Eric Garver
722b012166 network: firewalld: add zone for routed networks
This zone will be used for the routed network by default.

Note that this zone definition omits "forward" aka intra-zone
forwarding, because it requires firewalld >= 0.9.0.

Signed-off-by: Eric Garver <eric@garver.life>
Reviewed-by: Laine Stump <laine@redhat.com>
2022-11-05 14:34:47 -04:00
Eric Garver
d0e4d2fde7 util: add virFirewallDPolicyExists()
Signed-off-by: Eric Garver <eric@garver.life>
Reviewed-by: Laine Stump <laine@redhat.com>
2022-11-05 14:34:42 -04:00
Eric Garver
ab56f84976 util: add virFirewallDGetPolicies()
Signed-off-by: Eric Garver <eric@garver.life>
Reviewed-by: Laine Stump <laine@redhat.com>
2022-11-05 14:34:37 -04:00
Michal Privoznik
7416d19b8d qemu: Retire QEMU_CAPS_OBJECT_MEMORY_FILE_ALIGN
Now that nothing uses this capability, it can be retired.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-04 15:27:43 +01:00
Michal Privoznik
fc141bfe88 qemu_capabilities: Stop detecting QEMU_CAPS_OBJECT_MEMORY_FILE_ALIGN
All supported QEMUs have this capability. Stop detecting it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-04 15:27:43 +01:00
Michal Privoznik
8d5c564622 qemu: Assume QEMU_CAPS_OBJECT_MEMORY_FILE_ALIGN
Introduced in QEMU's commit of v2.12.0-rc0~148^2~4 the .align
attribute of memory-backend-file is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-04 15:27:43 +01:00
Michal Privoznik
536f561d13 qemu: Retire QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD
Now that nothing uses this capability, it can be retired.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-04 15:27:43 +01:00
Michal Privoznik
881cf3c4f1 qemu_capabilities: Stop detecting QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD
All supported QEMUs have this capability. Stop detecting it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-04 15:27:43 +01:00
Michal Privoznik
8c0d43803b qemu: Assume QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD
Introduced in QEMU's commit of v2.11.0-rc0~95^2~9 the .discard
attribute of memory-backend-file is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-04 15:27:42 +01:00
Michal Privoznik
9d86ae4ca2 qemu: Retire QEMU_CAPS_OBJECT_MEMORY_FILE
Now that nothing uses this capability, it can be retired.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-04 15:27:42 +01:00
Michal Privoznik
9b279f2d3e qemu_capabilities: Stop detecting QEMU_CAPS_OBJECT_MEMORY_FILE
All supported QEMUs have this capability. Stop detecting it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-04 15:27:42 +01:00
Michal Privoznik
8641fcfa63 qemu: Assume QEMU_CAPS_OBJECT_MEMORY_FILE
Introduced in QEMU's commit of v2.1.0-rc0~41^2~26 only for Linux,
and later in v3.1.0-rc0~71^2~10 for all POSIX, the
memory-backend-file is going to be present for all QEMU versions
we support (4.2.0, currently). Therefore, we can assume the
capability is always set and thus doesn't need to be checked for.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-04 15:27:42 +01:00
Michal Privoznik
7addd1baa6 qemu: Retire QEMU_CAPS_OBJECT_MEMORY_RAM
Now that nothing uses this capability, it can be retired.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-04 15:27:42 +01:00
Michal Privoznik
b77f5b08a7 qemu_capabilities: Stop detecting QEMU_CAPS_OBJECT_MEMORY_RAM
All supported QEMUs have this capability. Stop detecting it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-11-04 15:27:42 +01:00