Move the test invocation and rename the test files according to the
pattern.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The 'borzoi' machine doesn't honour '-usb' in qemu so use it as an
example for the upcoming patch for removing '-usb' support.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Add test data for a 'realview' machine example to validate default USB
controller selection.
Note that it's unlikely that anyone would run 'realview' machines with
'aarch64' architecture, but qemu allows it and it's simpler test-wise in
libvirt.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Add capabilities based on a dump from x86_64 host running Fedora for the
qemu-system-arm binary.
The test dump will be used for illustration of USB controller model
selection.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Allow using armv7l arch in a capability dump.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Document the reality that some dumps were faked for purpose of testing
corner cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Mention the new 'scripts/qemu-replies-tool.py'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Ideally check='partial' would check exactly the features QEMU would want
to enable when asked for a specific CPU model (and features). But there
is no way we could ask QEMU how a specific CPU would look like. So we
use our definition from CPU map, which may slightly differ as QEMU adds
or removes features from CPU models, and thus we may end up checking
features which QEMU would not enable while missing some required ones.
We can do better in specific cases, though. If a CPU definition uses
only a model and disabled features (or none at all), we already know
whether QEMU can enable all features required by the CPU model as that's
what we use to set usable='yes' attribute in the list of available CPU
models in domain capbilities XML. So when a usable CPU model is
requested without asking for additional features (disabling features is
fine) we can avoid our possible inaccurate check using our CPU map.
For backward compatibility we only consider usable models. If a
specified model is not usable, we still check it the old way and even
let QEMU start it (and disable some features) in case our definition
lacks some features compared to QEMU.
Fixes: https://gitlab.com/libvirt/libvirt/-/issues/608
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Recently a kernel bug caused QEMU to report a CPU feature as enabled
while listing it in the "unavailable-features" list of features that
were requested, but could not be enabled. The feature was actually
enabled, but we marked it as disabled when starting a domain. Later when
the domain is migrated, the destination requests the feature to be
disabled, which breaks the guest ABI or if we are lucky QEMU just fails
to load the migration stream.
Let's make similar bugs more visible in the future by refusing to even
start the domain.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Trying to print pages of a size larger than the UINT_MAX of the
given platform (for example, 4G on 64-bit ARM), results in a
system error even though this is a legitimate request.
The vshCommandOptScaledInt() used for parsing the pagesize is
given UINT_MAX as the upper limit. The parsed value is then
divided by 1024 and fed to virNodeGetFreePages() which expects an
unsigned int. We can't change the public API but the upper limit
can be raised by the factor of 1024.
Resolves: https://issues.redhat.com/browse/RHEL-23608
Signed-off-by: Adam Julis <ajulis@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Picks up the switch from FreeBSD 13.2 to 13.3
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is guaranteed to keep failing even after loongarch64
support is introduced.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This fails to be parsed because libvirt doesn't yet know about
the architecture, but thanks to the recent improvements this
is a merely a local failure rather than bringing everything
else down with it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
At the moment, any kind of issue being detected in any of the
firmware descriptor files will result in the entire process
being aborted.
In particular, installing a build of edk2 for an architecture
that libvirt doesn't yet know about, for example loongarch64,
will break most firmware-related functionality: it will no
longer be possible to define new EFI VMs, start existing ones,
or even just obtain the domcapabilities for any architecture.
This is obviously unnecessarily harsh. Adopt a more relaxed
approach and simply ignore the firmware descriptors that we
are unable to parse correctly.
https://bugzilla.redhat.com/show_bug.cgi?id=2258946
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Instead of returning the list of paths exactly as obtained
from qemuFirmwareFetchConfigs(), and allocating the list of
firmwares to be exactly that size right away, start with two
empty lists and add elements to them one by one.
At the moment this only makes things more verbose, but later
we're going to change things so that it's possible that some
of the paths/firmwares are not included in the lists returned
to the caller, and at that point the changes will pay off.
Note that we can't use g_auto() for the new list of paths,
because until the very last moment it's not null-terminated,
so g_strfreev() wouldn't be able to handle it correctly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In a couple of cases, we were reporting an error without
actually terminating the parse process.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Ensure that all rows have 3 columns and avoid generation of emtpy
elements which would be turned by the XML formatter into non-pair td/tr
tags which don't work properly with HTML5 parsers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The source document can contain an empty '@flags' attribute which passes
the test but generates an empty element. Check that flags is non-empty
to trigger the fallback.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The HTML standard requires that a table column must include at least one
row which defines it exclusively, thus having a table where all rows
unite it via 'colspan' is illegal.
Modify the enum value generator to always output the description field
even when it's empty rather than uniting it, as in case when each value
doesn't have a description the generated document would violate the
standard.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The various objects we generate API for may have empty description in
which case an empty div would be generated when processing the API
description. As we're using XML output mode the generator would shorten
such divs to the non-pair empty element version, which doesn't work well
with HTML5 parsers requiring a pair tag for <div>
Avoid empty description <div> elements altogether by skipping it if the
description is empty.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
If an API has no ACLs an empty <div class='acl'/> would be generated
which is mis-interpreted by browsers when creating DOM to nest any
subsequent elements under it.
Don't generate the ACL section div unless it will be filled.
Best viewed with 'git show -w'
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Similarly to previous commit drop the 'type' attribute which is frowned
upon by the HTML standard.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Per the w3 html validator a HTML/XML comment is not allowed inside the
<script> tag, use a space instead as it must be a pair tag.
Additionally drop the 'type' attribute as it's not needed (validator
warns about it).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Per the w3 HTML validator the 'lang' attribute is suggested.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Skip the XML header as it's invalid with <!DOCTYPE HTML> both for the
RST-generated pages and for the API docs generated from the API XML.
Additionally remove the spurious xsl:output directive from newapi.xsl
which is ignored and thus misleading.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Ever since this function was introduced in 2012 it could've tried
filling in an extra interface name. That was made worse in 2019 when
the caller functions started accepting NULL arrays of size 0.
This is assigned CVE-2024-1441.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reported-by: Alexander Kuznetsov <kuznetsovam@altlinux.org>
Fixes: 5a33366f5c
Fixes: d6064e2759
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Mention improvement of virt-admin, and fixes for the VPD xml and disk
migration port bug.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Adding 'save' ACL to REMOTE_PROC_NODE_DEVICE_DEFINE_XML to make
REMOTE_PROC_NODE_DEVICE_UPDATE ACLs meaningful.
Fixes: 69f9e7dbc2
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
On Fedora 41, bash-completion's .pc file moved to
`bash-completion-devel`.
Using `pkgconfig()` lets us handle this without distro version checks
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Regenerate the ci files using the latest libvirt-ci:
commit face9746f9729699ae8525ffac4ee19be82c1ba5
ci: drop update-alternatives for opensuse tumbleweed
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
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>
There are two memleaks inside of nodedevmdevctltest:
1) In the testCommandDryRunCallback() - when appending lines to
stdinbuf the pointer is overwritten without freeing the old
memory it pointed to.
2) In testMdevctlModify() the livecmd variable is reused and
since its marked as g_autoptr() the first use leaks.
Fixes: 582f27ff15
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Make sure that they're entirely contained within a single line
and that punctuation is used in a way that doesn't make the
resulting HTML look weird.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Address several oddities, and bring them in line with the style
used for the vast majority of our documentation. In a couple of
cases, some of the possible values for an attribute were listed
with :since: information matching that off the attribute itself,
making it redundant.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Tweak things so that the required kernel version is still
listed, just not as part of the :since: tag.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
