- 09 11月, 2019 5 次提交
-
-
由 Pavel Hrdina 提交于
Move generated_files variable closer to the sc_po_check rule and remove non-existent gnulib internal path. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Pavel Hrdina 提交于
Introduce new rule 'generated-sources' as a helper for PO files check to make sure that all generated files are prepared and to not duplicate the list on different places. This will be used as a dependency for sc_po_check rule instead of duplicated list of generated files. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Pavel Hrdina 提交于
Commit <22d8e27c> introduced our syntax-check.mk file based on gnulib rules. However, the rule was completely ignored as we don't have POTFILES.in file. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Pavel Hrdina 提交于
Now that we forbid builds in source directory we can remove a lot of ignores that are created during build time. To make the cleanup easier in the future create a sections in our .gitignore file. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Pavel Hrdina 提交于
Historically we've allowed builds in the main src dir, but meson does not support this. Explicitly force separate build dir in autotools to align with meson. We must re-enable dependency tracking which the RPM %configure macro turns off. Without this, the build dir doesn't get the source directory tree mirrored. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 08 11月, 2019 7 次提交
-
-
由 Michal Privoznik 提交于
The qemuDomainGetStatsIOThread() accesses the monitor by calling qemuDomainGetIOThreadsMon(). And it's also marked as "need monitor" in qemuDomainGetStatsWorkers[]. However, it's not checking if acquiring job was successful. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJonathon Jongsma <jjongsma@redhat.com>
-
由 Michal Privoznik 提交于
The qemuDomainObjEnterMonitor() should not be called without a job set. Catch this error and produce a warning message if such call occurred. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJonathon Jongsma <jjongsma@redhat.com>
-
由 Wang Yechao 提交于
Libvirtd has set SIGPIPE to ignored, and virFork resets all signal handlers to the defaults. But child process may write logs to stderr/stdout, that may generate SIGPIPE if journald has stopped. So set SIGPIPE to a dummy no-op handler before unmask signals in virFork(), and the handler will get reset to SIG_DFL when execve() runs. Now we can delete sigaction() call entirely in virExec(). Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Signed-off-by: NWang Yechao <wang.yechao255@zte.com.cn>
-
由 Laine Stump 提交于
When libvirt first implemented a stable and configurable MAC address for the bridges created for libvirt virtual networks (commit 5754dbd5, in libvirt v0.8.8) most distro stable releases didn't support explicitly setting the MAC address of a bridge; the bridge just always assumed the lowest numbered MAC of all attached interfaces. Because of this, we stabilized the bridge MAC address by creating a "dummy" tap interface with a MAC address guaranteed to be lower than any of the guest tap devices' MACs (which all started with 0xFE, so it's not difficult to do) and attached it to the bridge - this was the inception of the "virbr0-nic" device that has confused so many people over the years. Even though the linux kernel had recently gained support for explicitly setting a bridge MAC, we deemed it unnecessary to set the MAC that way, because the other (indirect) method worked everywhere. But recently there have been reports that the bridge MAC address was not following the setting in the network config, and mismatched the MAC of the dummy tap device (which was still correct). It turns out that this is due to a change in systemd-242 that persists whatever MAC address is set for a bridge when it's initially started. According to the systemd NEWS file entry for version 242 (https://github.com/systemd/systemd/blob/master/NEWS): "if a bridge interface is created without any slaves, and gains a slave later, then now the bridge does not inherit slave's MAC." This change was the result of: https://github.com/systemd/systemd/issues/3374 (apparently if there is no MAC saved for a bridge by the name of a bridge being created, the random MAC generated during creation is saved, and then that same MAC is used to explicitly set the MAC each time it is created). Once a bridge has an explicitly set MAC, the "use the lowest numbered MAC of attached devices" rule is ignored, so our dummy tap device is like the goggles - it does nothing! (well, almost). We could whine about changes in default behavior, etc. etc., but because the change was in response to actual user problems, that seems likely a fruitless task. Fortunately, time has marched on, and even distro releases that are old enough that they are no longer supported by upstream libvirt (e.g. RHEL6) have support for explicitly setting a bridge device MAC address, either during creation or with a separate ioctl after creation, so we can now do that. To enable explicitly setting the mac during bridge creation, we add a mac arg to virNetDevBridgeCreate(). In the case of platforms where the bridge is created with a netlink RTM_NEWLINK message, we just add that mac to the message. For platforms that still use an ioctl (either SIOCBRADDBR or SIOCIFCREATE2), we make a separate call to virNetDevSetMAC() after creating the bridge. (NB: I was unable to test the calling of virNetDevSetMAC() from the SIOCIFCREATE2 (BSD) version of virNetDevBridgeCreate(); even though I managed to get a FreeBSD system setup and libvirt built there, when I tried to start the default network the SIOCIFCREATE2 ioctl itself failed, so it never even got to the virNetDevSetMAC(). That leaves the FreeBSD implementation untested.) This makes the dummy tap pointless for purposes of setting the MAC address, but it is still useful for IPv6 DAD initialization (which apparently requires at least one interface to be attached to the bridge and online), as well as for setting an initial MTU for the bridge, so it hasn't been removed. (NB: we can safely *always* call virNetDevBridgeCreate() with &def->mac from the network driver because, in spite of the existence of a "mac_specified" bool in the config suggesting that it may not always be present, in reality a mac address will always be added to any network that doesn't have one - this is guaranteed in all cases by commit a47ae7c0) https://bugzilla.redhat.com/show_bug.cgi?id=1760851Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Laine Stump 提交于
Although until now, any use of the extra_args argument (a pointer to a struct containing extra attributes to add the the RTM_NEWLINK message) would always have the ifindex and mac set, so the code could assume it was safe to add both to the message if extra_args != NULL. There is now a use for setting a MAC address in the RTM_NEWLINK without setting the ifindex, so we should check each of these separately. Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Andrea Bolognani 提交于
The file was introduced in be03587a, but it was not added to $(cpumap_DATA) at the time and so it didn't show up in the distribution archive. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Laine Stump 提交于
Commit 01ca4010 (libvirt v5.1.0) moved address reservation for hotplugged interface devices up to an earlier point in qemuDomainAttachNetDevice(), because that function calls qemuDomainSupportsNicdev() (in the case of VIR_DOMAIN_NET_TYPE_VHOSTUSER), and qemuDomainSupportsNicdev() needs to know the address type (for ARM machinetypes) and returns incorrect results when the address type is "none". This bugfix unfortunately caused a regression, because it also made PCI address reservation happen before we noticed that the device was a *hostdev* interface. Those interfaces are hotplugged by just calling out to qemuDomainAttachHostdevDevice() - that function would then also attempt to reserve the *same PCI address* that had just been reserved in qemuDomainAttachNetDevice(). The solution is to move the bit of code that short-circuits out to virDomainHostdevAttach() up *even earlier* so that no PCI address has been allocated by the time it's called. https://bugzilla.redhat.com/show_bug.cgi?id=1744523Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
- 07 11月, 2019 19 次提交
-
-
由 Andrea Bolognani 提交于
Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Tested-by: NAndrew Jones <drjones@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Andrea Bolognani 提交于
Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Tested-by: NAndrew Jones <drjones@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Andrea Bolognani 提交于
This introduces semantic validation for SVE-related features, preventing the user from combining them in invalid ways; it also automatically enables overall SVE support if any SVE vector length has been enabled by the user to make sure QEMU behaves correctly. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Tested-by: NAndrew Jones <drjones@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Andrea Bolognani 提交于
For now we only perform very basic validation, such as making sure that the user is not trying to enable/disable unknown CPU features and the like. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Tested-by: NAndrew Jones <drjones@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Andrea Bolognani 提交于
The only feature we care about for the moment is SVE, which can be controlled both with a coarse granularity by turning it on/off completely and with a finer granularity by enabling/disabling individual vector lengths. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Tested-by: NAndrew Jones <drjones@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Andrea Bolognani 提交于
The ARM implementation of query-cpu-model-expansion only supports full expansion, so we have to make sure we're using that expansion mode if we want to obtain any useful data. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Tested-by: NAndrew Jones <drjones@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Andrea Bolognani 提交于
CPU features are available on ARM only wherever the query-cpu-model-expansion QMP command is available, same as on s390. Update qemuBuildCpuModelArgStr() to reflect this fact. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Tested-by: NAndrew Jones <drjones@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Andrea Bolognani 提交于
Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Tested-by: NAndrew Jones <drjones@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Andrea Bolognani 提交于
Mirrors the existing QEMU_CAPS_X86_MAX_CPU. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Tested-by: NAndrew Jones <drjones@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Andrea Bolognani 提交于
We're going to use it on non-x86 soon, so it needs a more generic name: virQEMUCapsObjectPropsMaxCPU. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Tested-by: NAndrew Jones <drjones@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Andrea Bolognani 提交于
Unfortunately this results in a lot of churn because of the eigth hundred and change QEMU commits since the file was last touched, but the only part we actually care about is the fact that the query-cpu-model-expansion QMP command is now available on aarch64. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Tested-by: NAndrew Jones <drjones@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
It's possible that virBitmapNewString returns NULL with an error string (and not an allocation failure that would abort); however, if virBitmapToString is called with a NULL @bitmap, then it will fail in an ugly manner. So rather than have if (!map && !str) logic, split the checks for each variable. Found by Coverity Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 John Ferlan 提交于
Commit 1c8113f9 added the call to virTypedParamsGetString without a return value check which caused Coverity to complain especially since other checks for the same function are made. Found by Coverity Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 John Ferlan 提交于
Commit 07552343 added a direct reference to @cookie even though it may be NULL as shown by a comment a few lines previous - so add the check here as well. Found by Coverity Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 John Ferlan 提交于
The @ifname is listed as an ATTRIBUTE_NONNULL(1) parameter, so checking for _NULLABLE causes a coverity build failure - remove that and if it's NULL for the test let's fail miserably. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 John Ferlan 提交于
Commit 66e2adb2 moved the code and the coverity comment which now was useless since the context was in lxcContainerSetupPivotRoot. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 John Ferlan 提交于
Commit 944a35d7 added @fakerootdir; however, there are multiple paths out of mymain that didn't free the memory - so just use the g_autofree to resolve the potential leak. Found by Coverity Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 John Ferlan 提交于
Commit 17561eb3 modified the logic to check "if (!event)" for an attribute that was not supposed to be passed as NULL. This causes the static checker/Coverity build to fail. Since the check is made, alter the header. Also add an error message since returning -1 without some sort of error message as previously would have happened with the failed VIR_STRDUP so that the eventual error doesn't get the default for some reason message. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 John Ferlan 提交于
The @valueTypeUtf8 references need to use the STREQ_NULLABLE since they're variantly filled in by @valueTypeUtf16. Found by Coverity. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 06 11月, 2019 2 次提交
-
-
由 Andrea Bolognani 提交于
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Daniel Veillard 提交于
* doc/news.xml: update for release Signed-off-by: NDaniel Veillard <veillard@redhat.com>
-
- 05 11月, 2019 4 次提交
-
-
由 Andrea Bolognani 提交于
A few new companies and individuals contributed to libvirt since the last time the gitdm configuration was updated. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
-
由 Andrea Bolognani 提交于
Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
-
由 Andrea Bolognani 提交于
Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NLaine Stump <laine@redhat.com>
-
由 Andrea Bolognani 提交于
The "Security" section has been used in the past, so we're only documenting existing behavior; the "Packaging changes" will be used in the next commit, as well as in future releases when we make more changes that are relevant to packagers, such as the switch to Meson. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NLaine Stump <laine@redhat.com>
-
- 02 11月, 2019 1 次提交
-
-
由 Jim Fehlig 提交于
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
- 01 11月, 2019 2 次提交
-
-
由 Jim Fehlig 提交于
Signed-off-by: NJim Fehlig <jfehlig@suse.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jim Fehlig 提交于
Xen support for specifying ACPI firmware path was introduced in the 5.9.0 dev cycle, not 5.8.0 as currently indicated by the docs. Signed-off-by: NJim Fehlig <jfehlig@suse.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-