- Mar 29, 2023
-
-
desc length should be always less than VIR_STORAGE_MAX_HEADER. If len = VIR_STORAGE_MAX_HEADER, desc may be out of bounds. Fixes: 296032bf ("util: extract storage file probe code into virtstoragefileprobe.c") Signed-off-by:
Anastasia Belova <abelova@astralinux.ru> Reviewed-by:
Ján Tomko <jtomko@redhat.com>
-
- Mar 28, 2023
-
-
Currently translated at 100.0% (10399 of 10399 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:
-
Currently translated at 83.4% (8679 of 10399 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/cs/ Co-authored-by:
-
Jano Tomko authored
Signed-off-by:
Andrea Bolognani <abologna@redhat.com>
-
Andrea Bolognani authoredThe changes to the output files are the exact opposite of those from commit 22207713: this is proof that the fix is working as intended, and that existing domains will keep using raw firmware images regardless of whether or not qcow2 images are available on the system and have higher priority. New domains will keep picking whatever firmware is considered the preferred one according to the order of descriptors, as evidenced by the fact that the recently introduced firmware-auto-efi-abi-update-aarch64 test case is unaffected. Signed-off-by:
Martin Kletzander <mkletzan@redhat.com>
-
Andrea Bolognani authored
The input is identical to that of the existing firmware-auto-efi-aarch64 test, but in this case we want to cover the scenario in which that input is used to define a new domain rather than loading the definition of an existing domain from disk. Signed-off-by:
-
Andrea Bolognani authored
Signed-off-by:
-
Michal Privoznik authored
There are couple of g_dbus_*() functions we provide an alternative implementation for in our virgdbusmock.c. However, these functions are declared in gio/gdbusconnection.h as: GIO_AVAILABLE_IN_ALL GDBusConnection *g_bus_get_sync (GBusType bus_type, GCancellable *cancellable, GError **error); where GIO_AVAILABLE_IN_ALL is declared as (in /gio/gio-visibility.h): #if (defined(_WIN32) || defined(__CYGWIN__)) && !defined(GIO_STATIC_COMPILATION) # define _GIO_EXPORT __declspec(dllexport) # define _GIO_IMPORT __declspec(dllimport) #elif __GNUC__ >= 4 # define _GIO_EXPORT __attribute__((visibility("default"))) # define _GIO_IMPORT #else # define _GIO_EXPORT # define _GIO_IMPORT #endif #ifdef GIO_COMPILATION # define _GIO_API _GIO_EXPORT #else # define _GIO_API _GIO_IMPORT #endif #define _GIO_EXTERN _GIO_API extern #define GIO_AVAILABLE_IN_ALL _GIO_EXTERN Now, on mingw the functions we mock are declared with dllimport attribute which makes the compiler unhappy: ../tests/virgdbusmock.c:25:24: error: 'g_bus_get_sync' redeclared without dllimport attribute: previous dllimport ignored [-Werror=attributes] The solution is to do what glib does when it compiles the gio module: set GIO_COMPILATION macro which in turn annotates the function with dllexport attribute. Signed-off-by:Michal Privoznik <mprivozn@redhat.com> Reviewed-by:
-
- Mar 27, 2023
-
-
Weblate authoredUpdated 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>
-
Jiri Denemark authoredSigned-off-by:Jiri Denemark <jdenemar@redhat.com>
-
- Mar 24, 2023
-
-
Martin Kletzander authored
This reverts commit 1f76b536. There were two issues with this commit. First is the missing propagation of CFLAGS into the build environment and second is the fact that this is not enough to disable the check for -fsemantic-interposition. The proper fix would require setting MESON_OPTS or similar and also add the propagation of such variable into the cirrus builds etc., but at this point I burned so much time on this trivial piece of rubbish that I think it's easier to just wait for macos to gain a newer clang =D Signed-off-by:
-
Michal Privoznik authored
While it's true that the default username is: administrator@${SSO-Domain} in majority of cases the ${SSO-Domain} is "vsphere.local". But our code (and what virsh displays then) says it's just "administrator". This is wrong also from a different POV: the username must contain the suffix no matter what and our default suggests otherwise. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2181234 Signed-off-by: -
Michal Privoznik authored
In vir-host-validate we do two checks related to IOMMU: 1) hardware support, and 2) kernel support. While users are usually interested in the latter, the former also makes sense. And for the former (hardware support) we have this huge if-else block for nearly every architecture, except ARM. Now, IOMMU is called SMMU in ARM world, and while there's certainly a definitive way of detecting SMMU support (e.g. via dumping some registers in asm), we can work around this - just like we do for Intel and AMD - and check for an ACPI table presence. In ARM world, there's I/O Remapping Table (IORT) which describes SMMU capabilities on given host and is exposed in sysfs (regardless of arm_smmu module). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2178885 Signed-off-by:
-
Martin Kletzander authored
This enables our CI to run tests on on macos-12 after commit 7944700b. Signed-off-by:
-
Martin Kletzander authored
This updates to FreeBSD 12.4 which has clang that supports -fsemantic-interposition, plus of course updates the system. Signed-off-by:
-
Michal Privoznik authored
There are some CLang versions that do not support -fsemantic-interposition. If that's the case, the code is optimized so much that our mocking no longer works. Therefore, disable tests and produce a warning. Signed-off-by:
-
- Mar 23, 2023
-
-
Peter Krempa authoredThe '15.3' version is EOL now: https://get.opensuse.org/leap/15.3/ Also switch the 'codestyle' job to the appropriate container image. Signed-off-by:
Peter Krempa <pkrempa@redhat.com> Reviewed-by:
-
Peter Krempa authored
As a precursor to dropping the EOL OpenSUSE 15.3 job add first the definitions for the replacement version. Signed-off-by:
-
- Mar 22, 2023
-
-
Currently translated at 99.5% (10368 of 10416 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/ja/ Co-authored-by:
-
Currently translated at 99.9% (10410 of 10416 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/fr/ Co-authored-by:
grimst <grimaitres@gmail.com> Signed-off-by:
-
Currently translated at 22.5% (2349 of 10416 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/fi/ Co-authored-by:
Jan Kuparinen <copper_fin@hotmail.com> Signed-off-by:
-
Michal Privoznik authored
The virConnectOpen(), well virConnectOpenInternal() reports an error if embed root is not an absolute path. This is a fair requirement, but our qemu_shim doesn't check this requirement and passes the path to mkdir(), only to fail later on, leaving the empty directory behind: $ ls -d asd ls: cannot access 'asd': No such file or directory $ virt-qemu-run -r asd whatever.xml virt-qemu-run: cannot open qemu:///embed?root=asd : unsupported configuration: root path must be absolute $ ls -d asd asd Signed-off-by:
Kristina Hanicova <khanicov@redhat.com>
-
Michal Privoznik authored
After cleanup done in v8.2.0-rc1~47 the qemuDomainObjExitMonitor() and after v8.7.0-rc1~176 the qemuDomainObjEnterMonitor() lost the @driver argument. But corresponding ATTRIBUTE_NONNULL() annotation was not removed and both functions are still annotated as ATTRIBUTE_NONNULL(2) even though they accept just one argument (@obj). Signed-off-by:
-
Jano Tomko authored
Otherwise looking up a secret fails when we try to elevate the identity in qemuDomainSecretInfoSetupFromSecret. https://bugzilla.redhat.com/show_bug.cgi?id=2000410 Signed-off-by:
-
Andrea Bolognani authored
Suggested-by:
-
Andrea Bolognani authored
The reason why it was in postparse in the first place was so that we could could automatically enable the secure-boot feature in some cases, but that no longer happens so we can finally move it to the proper location. Signed-off-by:
-
Andrea Bolognani authored
Now that we're adding information obtained from the firmware descriptor to the domain XML, this will happen automatically whenever a firmware that has the enrolled-keys feature ends up being selected. Signed-off-by:
-
Andrea Bolognani authored
Even when the user is not taking advantage of firmware autoselection and instead manually providing all the necessary information, in most cases they're still going to use firmware builds that are provided by the OS vendor, are installed in standard paths and come with a corresponding firmware descriptor. Similarly, even when the user is not guiding the autoselection process by specifying the desired status of certain features and instead is relying on the system-level descriptor priority being set up correctly, libvirt will still ultimately decide to use a specific descriptor, which includes information about the firmware's features. In both these cases, take the additional information that were obtained from the firmware descriptor and reflect them back into the domain XML, where they can be conveniently inspected by the user and management applications alike. Signed-off-by:
-
Andrea Bolognani authored
Now that we no longer reject configurations that include both this information and explicit firmware details, as long of course as everything is internally consistent, and that we've ensured that we produce maximally compatible XML on migration, we can stop stripping this information at the end of the firmware selection process. There are several advantages to keeping this information around: * if the user wants to change the firmware configuration for an existing VM, they can simply drop the <loader> and <nvram> elements, tweak the firmware autoselection parameters and let libvirt pick a firmware that matches on the new requirements; * management applications can inspect the XML and easily figure out firmware-related information without having to reverse-engineer them based on some opaque paths. Overall, this change makes things more transparent and easier to understand. The improvement is so significant that, in a follow-up commit, we're going to ensure that this information is available in even more cases. Signed-off-by: -
Andrea Bolognani authored
The combination of explicit firmware paths, which we now produce in all cases, and firmware autoselection knobs is explicitly rejected by libvirt 8.6.0 and newer. Right now we produce inherently migratable XML in all cases, since we always strip those bits, but that's going to change soon. To prepare for that, make sure that we always skip the problematic elements and attributes when preparing a migratable XML. The destination will simply receive a fully specified firmware configuration, which is indistinguishable from one that was manually provided by the user and is thus accepted by any old version of libvirt, regardless of whether or not firmware autoselection was used on the source host. Signed-off-by:
-
Andrea Bolognani authored
libvirt 8.6.0 introduced these checks and very clearly delineated two possible firmware selection scenarios: manual firmware selection, where the user is responsible for providing all information, and firmware autoselection, where a list of desired features is provided and everything else is handled by libvirt. In the interest of maintaining the clear separation between these two scenarios, setting most attributes when firmware autoselection is active will result in the configuration being rejected. This works fine, but is unnecessarily restrictive: in most cases, the additional information that the user has provided matches the information that libvirt would have discovered on its own by looking at firmware descriptors, and asking the user to scrub it from the XML only result in pointless friction. Remove these checks entirely. Unsurprisingly, this results in a few test cases that were rejected until now to suddenly start working and producing sensible results. The firmware-auto-efi-loader-path-nonstandard test case is notable: while we can now enable the xml2xml part of the test, the xml2argv part is still failing, although in a slightly different way. This is expected: since the firmware binary is a non-standard one, libvirt is unable to figure out the missing information from a firmware descriptor, and the configuration is still ultimately an invalid one. However, if we were to find such a configuration on disk at daemon startup, we would not ignore it completely and instead would offer the user a chance to fix it. Signed-off-by:
-
Andrea Bolognani authored
Right now there are a few scenarios in which we skip ahead, and removing these exceptions will make for more consistent and predictable behavior. Signed-off-by:
-
Andrea Bolognani authored
The requires-smm feature being present in a firmware descriptor causes loader.secure=yes to be automatically chosen for the domain, so we have to avoid this situation or the user's choice will be silently subverted. Note that we can't actually encounter loader.secure=no in this function at the moment because of earlier checks, but that's going to change soon. Signed-off-by:
-
Andrea Bolognani authored
Right now we have checks in place that ensure that explicit paths are not provided when firmware autoselection has been enabled, but that's going to change soon. To prepare for that, take into account user-provided paths during firmware autoselection if present, and discard all firmware descriptors that don't contain matching information. Signed-off-by:
-
Andrea Bolognani authored
Right now we're checking that firmware descriptor masking works as intended by creating an empty file matching 60-ovmf-sb.json in name. However, that firmware descriptors contains the details for a perfectly valid and quite common situation: Secure Boot being supported by the firmware build, but being effectively disabled by the lack of certificates in the NVRAM template. Unmask that firmware descriptor, and instead create a dummy one that has higher priority than all other OVMF builds and points to paths that are obviously incorrect, which should make it easy to notice it getting accidentally unmasked in the future. Signed-off-by:
-
Andrea Bolognani authored
These cover the same scenarios as the matching test cases for autoselection. Signed-off-by:
-
Andrea Bolognani authored
This is identical to the existing firmware-auto-efi-loader-path-nonstandard test case, but uses a standard firmware path. Right now the two test cases behave identically, but that's going to change in the future. Signed-off-by:
-
Andrea Bolognani authored
This test is intended to simulate the use of an OVMF firmware image installed under a non-standard path. In order to make such a configuration work, the user would have to provide additional information. Right now it doesn't matter, because the configuration is rejected anyway, but the behavior is going to change slightly in the future. Prepare by making the configuration more complete and realistic. Signed-off-by:
-
Andrea Bolognani authored
This unifies the naming between the manual and automatic selection cases, clarifies the contents of the tests and makes room for more tests being added in the future. Signed-off-by:
-
Andrea Bolognani authored
Signed-off-by:
Laine Stump <laine@redhat.com>
-
