- 16 6月, 2020 21 次提交
-
-
由 John Ferlan 提交于
Since ceb3255c, @absFile is leaked. Found by Coverity. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 John Ferlan 提交于
Since 9ea90206, @drvpath could be overwritten if we jumped to recheck Found by Coverity. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 John Ferlan 提交于
Since 5b82f7f3, @path should have been placed inside the for loop since it'd need to be free'd for each pass through the loop; otherwise, we'd leak like a sieve. Found by Coverity. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 John Ferlan 提交于
Since 5084091a, @authcred is filled by a g_key_file_get_string which is now an allocated string as opposed to some hash table lookup value, so we need to treat it as so. Found by Coverity Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 John Ferlan 提交于
Since 5084091a, @tmp is filled by a g_key_file_get_string which is now an allocated string as opposed to some hash table lookup value, so we need to treat it as so. Found by Coverity Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Daniel Henrique Barboza 提交于
On Linux, changing the nodeset on 'numatune' does not imply that the guest memory will be migrated on the spot to the new nodeset. The memory migration is tied on guest usage of the memory pages, and an idle guest will take longer to have its memory migrated to the new nodeset. This is a behavior explained in detail in the Linux kernel documentation in Documentation/admin-guide/cgroup-v1/cpusets.rst. The user doesn't need this level of detail though - just needs his/her expectations under check. Running 'numastat' and hoping for instant memory migration from the previous nodeset to the new one is not viable. There's also parts of the memory that are locked by QEMU in the same place, e.g. when VFIO devices are present. Let's also mention it as another factor that impacts the results the user might expect from NUMA memory migration with numatune. https://bugzilla.redhat.com/show_bug.cgi?id=1640869Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Peter Krempa 提交于
Commit 068efae5 accidentally removed the slash. https://bugzilla.redhat.com/show_bug.cgi?id=1847234Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jiri Denemark 提交于
Domains are now allowed to be pinned to host CPUs with IDs up to 16383. The new limit is as arbitrary as the old one. It's just bigger. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Viktor Mihajlovski 提交于
Protected virtualization/IBM Secure Execution for Linux protects guest memory and state from the host. Add some basic information about technology and a brief guide on setting up secure guests with libvirt. Signed-off-by: NViktor Mihajlovski <mihajlov@linux.ibm.com> Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Boris Fiuczynski 提交于
Update document with changes in qemu capability caching and the added secure guest support checking for AMD SEV in virt-host-validate. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Boris Fiuczynski 提交于
Add checking in virt-host-validate for secure guest support on x86 for AMD Secure Encrypted Virtualization. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Boris Fiuczynski 提交于
Add checking in virt-host-validate for secure guest support on s390 for IBM Secure Execution. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: NViktor Mihajlovski <mihajlov@linux.ibm.com> Reviewed-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Paulo de Rezende Pinatti 提交于
Implement secure guest check for AMD SEV (Secure Encrypted Virtualization) in order to invalidate the qemu capabilities cache in case the availability of the feature changed. For AMD SEV the verification consists of: - checking if /sys/module/kvm_amd/parameters/sev contains the value '1': meaning SEV is enabled in the host kernel; - checking if /dev/sev exists Signed-off-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com> Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Paulo de Rezende Pinatti 提交于
This patch introduces a common function to verify if the availability of the so-called Secure Guest feature on the host has changed in order to invalidate the qemu capabilities cache. It can be used as an entry point for verification on different architectures. For s390 the verification consists of: - checking if /sys/firmware/uv is available: meaning the HW facility is available and the host OS supports it; - checking if the kernel cmdline contains 'prot_virt=1': meaning the host OS wants to use the feature. Whenever the availability of the feature does not match the secure guest flag in the cache then libvirt will re-build it in order to pick up the new set of capabilities available. Signed-off-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com> Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: NViktor Mihajlovski <mihajlov@linux.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Paulo de Rezende Pinatti 提交于
Introduce two utility functions to parse a kernel command line string according to the kernel code parsing rules in order to enable the caller to perform operations such as verifying whether certain argument=value combinations are present or retrieving an argument's value. Signed-off-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com> Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Laine Stump 提交于
Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Laine Stump 提交于
This was mostly boilerplate conversion, but in one case I needed to define several differently named char* to take the place of a single char *tmp that was re-used multiple times, and in another place there was a single char* that was used at the toplevel of the function, and then later used repeatedly inside a for loop, so I defined a new separate char* inside the loop. Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Daniel P. Berrangé 提交于
Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: NLaine Stump <laine@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Historically IPv6 did not support NAT, so when IPv6 was added to libvirt's virtual networks, when requesting <forward mode="nat"/> libvirt will NOT apply NAT to IPv6 traffic, only IPv4 traffic. This is an annoying historical design decision as it means we cannot enable IPv6 automatically. We thus need to introduce a new attribute <forward mode="nat"> <nat ipv6="yes"/> </forward> Reviewed-by: NLaine Stump <laine@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
IPv6 does support masquerade since Linux 3.9.0 / ip6tables 1.4.18, which is Fedora 18 / RHEL-7 vintage, which covers all our supported Linux versions. Reviewed-by: NLaine Stump <laine@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 15 6月, 2020 11 次提交
-
-
由 Michal Privoznik 提交于
In v6.4.0-rc1~143 I've introduced a check that is supposed to return from the function early, if given path is not a dm target. While the idea is still valid, the implementation had a flaw. It calls stat() over given path and the uses major(sb.st_dev) to learn the major of the device. This is then passed to dm_is_dm_major() which returns true or false depending whether the device is under devmapper's control or not. The problem with this approach is in how the major of the device is obtained - paths managed by devmapper are special files and thus we want to be using st_rdev instead of st_dev to obtain the major number. Well, that's what virIsDevMapperDevice() does already so might as well us that. Fixes: 01626c66 Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1839992Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Michal Privoznik 提交于
When introducing virdevmapper.c (in v4.3.0-rc1~427) I didn't realize there is a function that calls in devmapper. The function is called virIsDevMapperDevice() and lives in virutil.c. Now that we have a special file for handling devmapper move it there. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Andrea Bolognani 提交于
The repository is now obsolete, and it never had proper GitLab CI support anyway. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
There are many different settings that required to config a KVM guest for real time, low latency workoads. The documentation included here is based on guidance developed & tested by the Red Hat KVM real time team. Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Peter Krempa 提交于
Compilers are not very good at detecting this problem. Fixed by manual inspection of compilation warnings after replacing 'VIR_FREE' with an empty macro. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com
-
由 Peter Krempa 提交于
If one of the early checks to get screen resolution fails 'screenData' would be passed to VIR_FREE uninitialized. Unfortunately the compiler isn't able to detect this when VIR_FREE is implemented using g_clear_pointer. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com
-
由 Peter Krempa 提交于
'uri_out' may be passed to VIR_FREE uninitialized if 'conn' is NULL. Unfortunately the compiler isn't able to detect this problem when VIR_FREE is implemented using g_clear_pointer. Initialize the variable. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com
-
由 Peter Krempa 提交于
Use VIR_FREE directly. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com
-
由 Peter Krempa 提交于
Use g_free directly to free the returned pointer from virTestLogContentAndReset rather than store it in a temp variable which was necessary when we only allowed VIR_FREE. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com
-
由 Peter Krempa 提交于
The path is formatted but then just freed without any use since introduction of the test function. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com
-
由 Peter Krempa 提交于
We can free 'def->name' directly. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com
-
- 12 6月, 2020 4 次提交
-
-
由 Andrea Bolognani 提交于
Debian sid is currently broken on mipsel, so use Debian 10 for that architecture; at the same time, move the ppc64le build from Debian 10 to Debian sid to keep things balanced. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Andrea Bolognani 提交于
The ci-* targets need to know where our container images are stored and how they are called to work, so now that we use the GitLab container registry instead of Quay some changes are necessary. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Andrea Bolognani 提交于
Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Andrea Bolognani 提交于
This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 11 6月, 2020 3 次提交
-
-
由 Andrea Bolognani 提交于
This needs to be set for every repository for Cirrus CI integration to work. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Yi Li 提交于
Signed-off-by: NYi Li <yili@winhong.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Andrea Bolognani 提交于
Right now we're dividing the jobs into three stages: prebuild, which includes DCO checking as well as building artifacts such as the website, and native_build/cross_build, which do exactly what you'd expect based on their names. This organization is nice from the logical point of view, but results in poor utilization of the available CI resources: in particular, the fact that cross_build jobs can only start after all native_build jobs have finished means that if even a single one of the latter takes a bit longer the pipeline will stall, and with native builds taking anywhere from less than 10 minutes to more than 20, this happens all the time. Building artifacts in a separate pipeline stage also doesn't have any advantages, and only delays further stages by a couple of minutes. The only job that really makes sense in its own stage is the DCO check, because it's extremely fast (less than 1 minute) and, if that fails, we can avoid kicking off all other jobs. Reducing the number of stages results in significant speedups: specifically, going from three stages to two stages reduces the overall completion time for a full CI pipeline from ~45 minutes[1] to ~30 minutes[2]. [1] https://gitlab.com/abologna/libvirt/-/pipelines/154751893 [2] https://gitlab.com/abologna/libvirt/-/pipelines/154771173Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 10 6月, 2020 1 次提交
-
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-