Commit Graph

50978 Commits

Author SHA1 Message Date
Jiri Denemark
f527da37be cpu_map: Fix SierraForest CPU model
The model was defined with two CPU features that cannot be explicitly
configured in QEMU (it knows the MSR bits, but there's no name
associated with them). The features should have never existed in the CPU
map. While removing them from the list of features and existing CPU
models is not trivial (to avoid compatibility issues), we can at least
fix the SierraForest CPU model added in this release cycle.

The rest will be handled later in a separate series.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-09-25 09:57:48 +02:00
Göran Uddeborg
97f41f4878 Translated using Weblate (Swedish)
Currently translated at 89.0% (9365 of 10521 strings)

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

Signed-off-by: Göran Uddeborg <goeran@uddeborg.se>
2024-09-25 08:37:35 +02:00
Cole Robinson
785dfad13c rpc: ssh: Allow SSH_ASKPASS_REQUIRE
openssh 8.4p1 released in Sep 2020 added a feature to force use
of SSH_ASKPASS

https://man.openbsd.org/ssh.1#SSH_ASKPASS_REQUIRE

Don't strip it from the environment

Signed-off-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-09-25 08:46:52 +02:00
Michal Privoznik
6126f743b1 qemu: Provide sane default for dump_guest_core
QEMU uses Linux extensions to madvise() to include/exclude guest
memory from core dump. These are obviously not available
everywhere. Currently, users have two options:

  1) configure <memory dumpCore=''/> in domain XML, or
  2) configure dump_guest_core in qemu.conf

While these work, they may harm user experience as "things just
don't work" out of the box. Provide sane default in
virQEMUDriverConfigNew() so neither of two options is required.

To have predictable results in tests, explicitly set
cfg->dumpGuestCore to false in qemuTestDriverInit() (which
creates cfg object for tests).

Resolves: https://gitlab.com/libvirt/libvirt/-/issues/679

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2024-09-25 08:38:09 +02:00
Michal Privoznik
18b61cb4f9 qemu.conf.in: Fix dumpCore capitalization
In qemu.conf.in we give examples of enabling/disabling core
dumps in domain XML. But the attribute is spelled wrong.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2024-09-25 08:38:09 +02:00
Göran Uddeborg
8287ca7119 Translated using Weblate (Swedish)
Currently translated at 88.8% (9345 of 10521 strings)

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

Signed-off-by: Göran Uddeborg <goeran@uddeborg.se>
2024-09-24 10:03:55 +02:00
Weblate
de8b3b9764 Translated using Weblate (Georgian)
Currently translated at 4.3% (458 of 10521 strings)

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

Signed-off-by: Weblate <noreply-mt-weblate@weblate.org>
2024-09-24 10:03:54 +02:00
Göran Uddeborg
badc4b44f8 Translated using Weblate (Swedish)
Currently translated at 88.4% (9304 of 10521 strings)

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

Signed-off-by: Göran Uddeborg <goeran@uddeborg.se>
2024-09-24 10:03:54 +02:00
Göran Uddeborg
ff94824125 Translated using Weblate (Swedish)
Currently translated at 88.1% (9272 of 10521 strings)

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

Signed-off-by: Göran Uddeborg <goeran@uddeborg.se>
2024-09-24 10:03:54 +02:00
Andi Chandler
d86dc9d308 Translated using Weblate (English (United Kingdom))
Currently translated at 49.3% (5196 of 10521 strings)

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

Signed-off-by: Andi Chandler <andi@gowling.com>
2024-09-24 10:03:54 +02:00
Göran Uddeborg
469824ce21 Translated using Weblate (Swedish)
Currently translated at 88.0% (9265 of 10521 strings)

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

Signed-off-by: Göran Uddeborg <goeran@uddeborg.se>
2024-09-24 10:03:54 +02:00
Martin Kletzander
6f0974ca32 qemu: Generate domain memory backing path directly
This makes qemuDomainGenerateMemoryBackingPath() nicer to call.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-09-24 10:12:08 +02:00
Martin Kletzander
f035f24777 qemu: Rename memory path functions
This way they make sense not only based on where they are located but
the name also relates to what they are actually doing.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-09-24 10:12:08 +02:00
Martin Kletzander
d599fc3d57 qemu: Make qemuGetMemoryBackingDomainPath static
After previous patches it is not used (and should not be used) outside
of qemu_domain.c.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-09-24 10:12:08 +02:00
Martin Kletzander
ff49d2a8c2 qemu: Use per-domain private memoryBackingDir for new memory backends
The function qemuGetMemoryBackingPath() does not need the @def any more
and priv->memoryBackingDir can be used instead of constructing the path
by calling qemuGetMemoryBackingDomainPath().

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-09-24 10:12:08 +02:00
Martin Kletzander
f58a4dc9d5 qemu: Set memoryBackingDir in private data upon start
This way we keep the path for each running VM.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-09-24 10:12:08 +02:00
Martin Kletzander
da8a1d7943 qemu: Add memoryBackingDir to qemuDomainObjPrivate
This way we _can_ (but do not, yet) remember the memory backing path for
running domains even after configuration change and daemon restart.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-09-24 10:12:08 +02:00
Martin Kletzander
c9a35eb255 qemu: Change parameters of qemuGetMemoryBackingDomainPath()
This way it does not use driver, since it will be later reworked and the
following patches cleaner, hopefully.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-09-24 10:12:08 +02:00
Martin Kletzander
edcf14be9c qemu: Move domain-related functions to qemu_domain
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-09-24 10:12:08 +02:00
Michal Privoznik
1c76827270 meson: Sort values reported in summary()
So far the only sorted summary() is list of detected libraries.
Other sections like hypervisor, storage, security drivers and
misc are in random order. Sort them alphabetically.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2024-09-24 09:59:00 +02:00
Michal Privoznik
794d49e3cf meson: Restore alphabetical order of reported libraries
One of previous commits introduced json-c library and reports it
in the summary at the end. However, we like the list to be sorted
alphabetically which is not the case.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2024-09-24 09:58:49 +02:00
Ján Tomko
6d09340d6f ci: drop yajl completely
It is no longer used by libvirt so it's pointless to install it.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-09-24 08:24:01 +02:00
Ján Tomko
81e532c701 util: json: remove yajl implementation
Since the previous commit removed YAJL detection completely,
WITH_YAJL cannot possibly be set. Drop the code.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-09-24 08:24:00 +02:00
Ján Tomko
d96e753d84 meson: options: drop yajl
Drop the yajl option and all references to it.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-09-24 08:24:00 +02:00
Ján Tomko
84198ad88a nss: convert findMACs to use json-c
While the parsing is still done by 1K buffers, the results
are no longer filtered during the parsing, but the whole JSON
has to live in memory at once, which was also the case before
the NSS plugin dropped its dependency on libvirt_util.

Also, the new parser might be more forgiving of missing elements.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-09-24 08:24:00 +02:00
Ján Tomko
a8d828c88b nss: convert findLeases to use json-c
While the parsing is still done by 1K buffers, the results
are no longer filtered during the parsing, but the whole JSON
has to live in memory at once, which was also the case before
the NSS plugin dropped its dependency on libvirt_util.

Also, the new parser might be more forgiving of missing elements.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-09-24 08:24:00 +02:00
Ján Tomko
9e6555fd90 util: json: write a json-c implementation
Write an alternative implementation of our virJSON functions,
using json-c instead of yajl.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-09-24 08:24:00 +02:00
Ján Tomko
28c9872639 meson: switch checks to depend on json-c as well as yajl
Ensure both are required during this series to make bisecting smooth.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-09-24 08:24:00 +02:00
Ján Tomko
1873b54512 meson: add option for building with json-c
Also disable it immediately for the mingw build because it's not
available there.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-09-24 08:24:00 +02:00
Ján Tomko
297fbcb346 ci: install json-c too
Install json-c to ensure the pipeline stays green throughout the series.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-09-24 08:24:00 +02:00
Ján Tomko
dcb7cfd149 build: introduce WITH_JSON
Some tests depend on WITH_YAJL even though the actual library used
does not make a difference. Introduce WITH_JSON for a smoother
transition.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-09-24 08:24:00 +02:00
Ján Tomko
8eba36d4b1 tests: switch to compact empty JSON object formatting
Some earlier versions of json-c format empty elements differently.
Run the tests who use the pretty formatting for readability and
diffability through a function that unifies the output.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-09-24 08:24:00 +02:00
Ján Tomko
330cf7f492 util: json: introduce virJSONStringPrettifyBlanks
A horribly named function for unifying formatting when pretty-printing
empty JSON arrays and objects. Useful for having stable test output
even if different JSON libraries format these differently.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-09-24 08:24:00 +02:00
Laine Stump
e14a5fcac4 util: use uint32 instead of char[4] for several virSocketAddrIPv4 operations
These 3 functions are easier to understand, and more efficient, when
the IPv4 address is viewed as a uint32 rather than an array of bytes.

virsocketAddrGetIPv4Addr() has bothered me for a long time - it was
doing ntohl of the address into a temporary uint32, and then a loop
one-by-one swapping the order of all the bytes back to network
order. Of course this only works as described on little-endian
architectures - on big-endian architectures the first assignment won't
swap the bytes' ordering, but the loop assumes the bytes are now in
little-endian order and "swaps them back", so the result will be
incorrect. (Do we not support any big-endian targets that would have
exposed this bug long before now??)

virSocketAddrCheckNetmask() was checking each byte of the two
addresses individually, when it could instead just do the operation
once on the full 32 bit values.

virSocketGetRange() was checking for "range > 65535" by seeing if the
first 2 bytes of the start and end were different, and then doing
arithmetic combining the lower two bytes (along with necessary bit
shifting to account for network byte order) to determine the exact
size of the range. Instead we can just get the ntohl of start & end,
and do the math directly.

Signed-off-by: Laine Stump <laine@redhat.com>
2024-09-21 15:06:09 -04:00
Laine Stump
009464902a util: make virSocketAddrIPv4 a union
virSocketAddrIPv4 is a type used only internally by
virsocketaddr.c. It is defined to be a character array, which leads to
multiple occurences of extra bit fiddling and byte swapping for no
good reason (except to confuse).

An IPv4 address is really just a uint32_t with the bytes in network
order, which is exactly the type of the s_addr member of the
sockaddr_in that is a part of the publicly consumed struct
virSocketAddr, and that we are copying in and out of a
virSocketAddrIPv4. Sometimes it's simpler to just treat it as a
network-order uint32_t, so let's make our virSocketAddrIPv4 a union
that has both an unsigned char bytes[4] (for the times when we need to
look one byte at a time) and a uint32_t val (for the times when it's
simpler to treat it as a single value).

For now we just change all the uses from, e.g. x[i] to x.bytes[y];
an upcoming patch will simplify some of the code to remove loops by
using x.val instead of x.bytes when appropriate.

Signed-off-by: Laine Stump <laine@redhat.com>
2024-09-21 14:39:05 -04:00
Laine Stump
14623a3424 util: fix virSocketAddrMask() when source and result are the same object
Many years ago (2011), virSocketAddrMask() had caused a bug by failing
to initialize an IPv6-specific field in the result virSocketAddr. This
was fixed by memset(0)ing the entire result (*network) at the
beginning of the function (thus making sure anything and everything
was initialized).

The problem is that virSocketAddrMask() has a comment above it that
says that the source (addr) and destination (network) arguments can
point to the same virSocketAddr. But in that case, the
memset(*network, 0) at the top of the function is actually doing a
memset(*addr, 0), and so there is nothing left for all the assignments
to copy except a giant field of 0's.

Fortunately in the 13 years since the memset was added, nobody has
ever called virSocketAddrMask() with addr and network being the same.

This patch makes the code agree with the comment by copying/masking
into a local virSocketAddr (which is initialized to all 0) and then
copying that to *network after it's finished assigning things from
addr.

Fixes: ba08c5932e
Signed-off-by: Laine Stump <laine@redhat.com>
2024-09-21 14:37:54 -04:00
Laine Stump
f7a2d158f7 network: fix argument order/log level in message about firewall_backend
Oops.

Fixes: 64b966558c
Signed-off-by: Laine Stump <laine@redhat.com>
2024-09-19 16:14:21 -04:00
Laine Stump
c7ea694f7d qemu: rework needBridgeChange/needReconnect decisions in qemuDomainChangeNet()
This patch simplifies (?) the of qemuDomainChangeNet() code while
fixing some incorrect decisions about exactly when it's necessary to
re-attach an interface's bridge device, or to fail the device update
(needReconnect[*]) because the type of connection has changed (or
within bridge and direct (macvtap) type because some attribute of the
connection has changed that can't actually be modified after the
tap/macvtap device of the interface is created).

Example 1: it's pointless to require the bridge device to be
reattached just because the interface has been switched to a different
network (i.e. the name of the network is different), since the new
network could be using the same bridge as the old network (very
uncommon, but technically possible). Instead we should only care if
the name of the *bridge device* changes (or if something in
<virtualport> changes - see Example 3).

Example 2: wrt changing the "type" of the interface, a change should
be allowed if old and new type both used a bridge device (whether or
not the name of the bridge changes), or if old and new type are both
"direct" *and* the device being linked and macvtap mode remain the
same. Any other change in interface type cannot be accommodated and
should be a failure (i.e. needReconnect).

Example 3: there is no valid reason to fail just because the interface
has a <virtualport> element - the <virtualport> could just say
"type='openvswitch'" in both the before and after cases (in which case
it isn't a change by itself, and so is completely acceptable), and
even if the interfaceid changes, or the <virtualport> disappears
completely, that can still be reconciled by simply re-attaching the
bridge device. (If, on the other hand, the modified <virtualport> is
for a type='direct' interface, we can't domodify that, and so must
fail (needReconnect).)

(I tried splitting this into multiple patches, but they were so
intertwined that the intermediate patches made no sense.)

[*] "needReconnect" was a flag added to this function way back in
2012, when I still believed that QEMU might someday support connecting
a new & different device backend (the way the virtual device connects
to the host) to an already existing guest netdev (the virtual device
as it appears to the guest). Sadly that has never happened, so for the
purposes of qemuDOmainChangeNet() "needReconnect" is equivalent to
"fail".

Resolves: https://issues.redhat.com/browse/RHEL-7036
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-09-19 13:56:39 -04:00
Laine Stump
601f4160b9 qemu: replace open-coded remove/attach bridge with virNetDevTapReattachBridge()
The new function does what the old qemuDomainChangeNetbridge() did
manually, except that:

1) the new function supports changing from a bridge of one type to
   another, e.g. from a Linux host bridge to an OVS
   bridge. (previously that wasn't handled)

2) the new function doesn't emit audit log messages. This is actually
   a good thing, because the old code would just log a "detach"
   followed immediately by "attach" for the same MAC address, so it's
   essentially a NOP. (the audit logs don't have any more detailed
   info about the connection - just the VM name and MAC address, so it
   makes no sense to log the detach/attach pair as it's not providing
   any information).

Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-09-19 13:56:31 -04:00
Laine Stump
e3f8bccea6 util: don't return early from virNetDevTapReattachBridge() if "force" is true
It can be useful to force an interface to be detached/reattached from
its bridge even if it's the same bridge - possibly something like the
virtualport profileID has changed, and a detach/attach cycle will get
it connected with the new profileID.

The one and only current use of virNetDevTapReattachBridge() sets
force to false, to preserve current behavior. An upcoming patch will
use it with force set to true.

Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-09-19 13:56:19 -04:00
Laine Stump
a37bd2a15b qemu: prevent unnecessarily failing live interface update
Attempts to use update-device to modify just the link state of a guest
interface were failing due to a supposed attempt to modify something
in the interface that can't be modified live (even though the only
thing that was changing was the link state, which *can* be modified
live).

It turned out that this failure happened because the guest interface
in question was type='network', and the network in question was a
'direct' network that provides each guest interface with one device
from a pool of network devices. As a part of qemuDomainChangeNet() we
would always allocate a new port from the network driver for the
updated interface definition (by way of calling
virDomainNetAllocateActualDevice(newdev)), and this new port (ie the
ActualNetDef in newdev) would of course be allocated a new host device
from the pool (which would of course be different from the one
currently in use by the guest interface (in olddev)). Because direct
interfaces don't support changing the host device in a live update,
this would cause the update to fail.

The solution to this is to realize that as long as the interface
doesn't get switched to a different network as a part of the update,
the network port information (ie the ActualNetDef) will not change as
a part of updating the guest interface itself. So for sake of
comparison we can just point the newdev at the ActualNetDef of olddev,
and then clear out one or the other when we're done (to avoid a double
free or, more likely, attempt to reference freed memory).

(If, on the other hand, the name of the network has changed, or if the
interface type has changed to type='network' from something else, then
we *do* need to allocate a new port (actual device) from the network
driver (as we used to do in all cases when the new type was
'network'), and also indicate that we'll need to replace olddev in the
domain with newdev (because either of these changes is major enough
that we shouldn't just try to fix up olddev)

Partially-Resolves: https://issues.redhat.com/browse/RHEL-7036
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-09-19 13:56:06 -04:00
Peter Krempa
852380cef5 qemuBuildChardevCommand: Remove unused variable
'charstr' is unused since 36d06a5637, breaking the build on some
platforms. Remove it.

Fixes: 36d06a5637
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2024-09-19 13:12:02 +02:00
Peter Krempa
24d468993c qemu: Reject unsupported chardev backend protocols
QEMU supports only 'raw' and 'telnet' in the

 <protocol type='telnets'/>

element. Reject 'telnets' and 'tls'. TLS transport for qemu chardevs is
configured via "tls='yes'" attribute added to the "<source>" element
instead, so this prevents potential misconfig as the value would be
silently accepted.

Closes: https://gitlab.com/libvirt/libvirt/-/issues/412
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-09-19 10:30:15 +02:00
Peter Krempa
3778964207 conf: Convert 'protocol' field of TCP char device backend to proper type
Use virDomainChrTcpProtocol as type, convert the parser to use
virXMLPropEnum and fix one switch statement in the VMX driver.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-09-19 10:30:15 +02:00
Peter Krempa
2256466f70 qemu: monitor: Remove the old chardev backend generator
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-09-19 10:30:15 +02:00
Peter Krempa
e352a692a7 qemu: Use the new chardev backend JSON props generator also in the monitor
Now that we have a unified generator of chardev backend which is also
validated against the QMP schema we can replace the old generator with
it.

This patch modifies the monitor code to take virJSONValue 'props'
instead of the chardev definition and adds the conversion from the
chardev definition to JSON on higher levels.

The monitor code now also attempts to extract the returned 'pty' if
returned from qemu, so higher level code needs to report the error if
the path is needed and missing.

The current monitor generator is for now abandoned in place and will be
removed later.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-09-19 10:30:15 +02:00
Peter Krempa
d897ad2b89 qemu: Move check for chardev backends which can't be hotplugged out of the monitor
The upcoming refactor of the monitor code will make the hotplug code
paths use the same generator we have for commandline -chardev backends
which doesn't refuse to format certain backends which can't be
hotplugged.

To prepare for this we add a check to qemuHotplugChardevAttach()
refusing such hotplug and remove 'qemumonitorjsontest' test cases which
will not make sense any more.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-09-19 10:30:14 +02:00
Peter Krempa
b8129d2530 qemuxmlconftest: Add test case for QMP schema validation of -chardev backends
Use the 'chardev-backends' test data as symlink to invoke the test case
again asserting QEMU_CAPS_CHARDEV_JSON which will make the commandline
generator use the JSON representation of the -chardev backend instead
allowing us to validate it agains the QMP schema.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-09-19 10:30:14 +02:00
Peter Krempa
e00739ff0d qemuxmlconftest: Add support for validating schema for 'chardev-add'
While qemu doesn't yet support JSON args for chardev, we can at least
for test purposes of schema validation plumb it to the '-chardev'
command as it's easier to create test cases via XML than to write them
into code in 'qemuhotplugtest'.

Additionally once this becomes available and if e.g. the syntax is fixed
we'll be able to also catch the differences early.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-09-19 10:30:14 +02:00
Peter Krempa
36d06a5637 qemu: Introduce unified chardev backend config generator
Similarly to how we approach the generators for
-device/-object/-blockdev/-netdev rewrite the generator of -chardev to
be unified with the generator for the monitor.

Unfortunately with -chardev it will be a bit more quirky when compared
to the others as the generator itself will need to know whether it
generates command line output or not as a few field names change and data
is nested differently.

This first step adds the generator and uses it only for command line
generation. This was possible to achieve without changing any of the
output in tests.

In further patches the same generator will then be used also in the
monitor code replacing both.

As basis for the generator I took the monitor code but modified it to
have the same field order as the commandline code and extended it
further to support all backend types, even those which are not
hotpluggable.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-09-19 10:30:14 +02:00