- 15 5月, 2019 2 次提交
-
-
由 Jiri Denemark 提交于
My earlier commit be46f613 was incomplete. It removed caching of microcode version in the CPU driver, which means the capabilities XML will see the correct microcode version. But it is also cached in the QEMU capabilities cache where it is used to detect whether we need to reprobe QEMU. By missing the second place, the original commit be46f613 made the situation even worse since libvirt would report correct microcode version while still using the old host CPU model (visible in domain capabilities XML). Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> (cherry picked from commit 673c62a3) CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 Conflicts: src/qemu/qemu_capabilities.c - virQEMUCapsCacheLookupByArch refactoring (commits 7948ad41 and 1a3de670) are missing - commit a7424faf "Force QMP capability probing" is missing downstream Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Jiri Denemark 提交于
The microcode version checks are used to invalidate cached CPU data we get from QEMU. To minimize /proc/cpuinfo parsing the microcode version was only read when libvirtd started and cached for the daemon's lifetime. However, the CPU microcode can change anytime (updating the microcode package can automatically upload it to the CPU) and we need to stop caching it to avoid using stale CPU model data. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> (cherry picked from commit be46f613)
-
- 19 6月, 2018 2 次提交
-
-
由 Daniel P. Berrangé 提交于
Some AMD processors only support a non-architectural means of enabling Speculative Store Bypass Disable. To allow simplified handling in virtual environments, hypervisors will expose an architectural definition through CPUID bit 0x80000008_EBX[25]. This needs to be exposed to guest OS running on AMD x86 hosts to allow them to protect against CVE-2018-3639. Note that since this CPUID bit won't be present in the host CPUID results on physical hosts, it will not be enabled automatically in guests configured with "host-model" CPU unless using QEMU version >= 2.9.0. Thus for older versions of QEMU, this feature must be manually enabled using policy=force. Guests using the "host-passthrough" CPU mode do not need special handling. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com> (cherry picked from commit 92673422)
-
由 Daniel P. Berrangé 提交于
New microcode introduces the "Speculative Store Bypass Disable" CPUID feature bit. This needs to be exposed to guest OS to allow them to protect against CVE-2018-3639. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com> (cherry picked from commit 1dbca2ec)
-
- 01 5月, 2018 1 次提交
-
-
由 Laine Stump 提交于
When an nwfilter rule sets the parameter CTRL_IP_LEARNING to "dhcp", this turns on the "dhcpsnoop" thread, which uses libpcap to monitor traffic on the domain's tap device and extract the IP address from the DHCP response. If libpcap on the host is built with HAVE_TPACKET3 defined (to enable support for TPACKET_V3), the dhcpsnoop code's initialization of the libpcap socket would fail with the following error: virNWFilterSnoopDHCPOpen:1134 : internal error: pcap_setfilter: can't remove kernel filter: Bad file descriptor It turns out that this was because TPACKET_V3 requires a larger buffer size than libvirt was setting (we were setting it to 128k). Changing the buffer size to 256k eliminates the error, and the dhcpsnoop thread once again works properly. A fuller explanation of why TPACKET_V3 requires such a large buffer, for future git spelunkers: libpcap calls setsockopt(... SOL_PACKET, PACKET_RX_RING...) to setup a ring buffer for receiving packets; two of the attributes sent to this API are called tp_frame_size, and tp_frame_nr. If libpcap was built with HAVE_TPACKET3 defined, tp_trame_size is set to MAXIMUM_SNAPLEN (defined in libpcap sources as 262144) and tp_frame_nr is set to: [the buffer size we set, i.e. PCAP_BUFFERSIZE i.e. 262144] / tp_frame_size. So if PCAP_BUFFERSIZE < MAXIMUM_SNAPLEN, then tp_frame_nr (the number of frames in the ring buffer) is 0, which is nonsensical. This same value is later used as a multiplier to determine the size for a call to malloc() (which would also fail). (NB: if HAVE_TPACKET3 is *not* defined, then tp_frame_size is set to the snaplen set by the user (in our case 576) plus a small amount to account for ethernet headers, so 256k is far more than adequate) Since the TPACKET_V3 code in libpcap actually reads multiple packets into each frame, it's not a problem to have only a single frame (especially when we are monitoring such infrequent traffic), so it's okay to set this relatively small buffer size (in comparison to the default, which is 2MB), which is important since every guest using dhcp snooping in a nwfilter rule will hold 2 of these buffers for the entire life of the guest. Thanks to Christian Ehrhardt for discovering that buffer size was the problem (this was not at all obvious from the error that was logged!) Resolves: https://bugzilla.redhat.com/1547237 Fixes: https://bugs.launchpad.net/libvirt/+bug/1758037Signed-off-by: NLaine Stump <laine@laine.org> Reviewed-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> (V1) Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Tested-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com> (cherry picked from commit ce5aebea)
-
- 02 3月, 2018 1 次提交
-
-
由 Andrea Bolognani 提交于
The check was trying to use the shell variable $CC instead of the make variable $(CC); it also interpreted grep's return code wrong: 1 means the provided pattern was *not* matched. As a result, pdwtags was never run, not even when building with gcc. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 01 3月, 2018 2 次提交
-
-
由 John Ferlan 提交于
Commit id 'edae027c' blindly assumed that the passed @oldDev parameter would not be NULL when calling virDomainDeviceGetInfo; however, commit id 'b6a264e8' passed NULL for AttachDevice callers under the premise that there wouldn't be a device to check/update against. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Daniel P. Berrangé 提交于
When building with CLang the structs that are emitted by pdwtags appear in a completely different order than with GCC, which causes the comparison against expected data to fail. Ideally the test would not be sensitive to the ordering, because even future GCC could cause changes, but that's not easy to fix. So for now just skip the test when using clang. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 28 2月, 2018 3 次提交
-
-
由 Nikolay Shirokovskiy 提交于
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
由 Zhangzijian 提交于
12 bytes in 1 blocks are definitely lost in loss record 188 of 1,145 at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x5D2CD77: xmlStrndup (in /lib/x86_64-linux-gnu/libxml2.so.2.7.8) by 0x514E137: virXMLPropString (virxml.c:506) by 0x234F51: qemuMigrationCookieNetworkXMLParse qemu_migration.c:1001) by 0x235FF8: qemuMigrationCookieXMLParse (qemu_migration.c:1333) by 0x236214: qemuMigrationCookieXMLParseStr (qemu_migration.c:1372) by 0x2365D2: qemuMigrationEatCookie (qemu_migration.c:1456) by 0x243DBA: qemuMigrationFinish (qemu_migration.c:6381) by 0x204032: qemuDomainMigrateFinish3 (qemu_driver.c:13228) by 0x521CCBB: virDomainMigrateFinish3 (libvirt-domain.c:4788) by 0x1936DE: remoteDispatchDomainMigrateFinish3 (remote.c:4580) by 0x16DBB1: remoteDispatchDomainMigrateFinish3Helper(remote_dispatch.h:7582) Signed-off-by: NZhangZijian <zhang.zijian@h3c.com>
-
由 Laine Stump 提交于
A problem encountered due to a bug in libpcap was reported to the caller as: An error occurred, but the cause is unknown This was because the error had been logged in the DHCPSnoop thread. The worker thread handling the API call to start a domain spins up the DHCPSnoop thread which watches for dhcp packets with libpcap, then uses virCondSignal() to notify the worker thread (which has been waiting with virCondWait()). The worker thread knows that there was an error (because threadStatus != THREAD_STATUS_OK), but the error info had been stored in thread-specific storage for the other thread, so the worker thread can only report that there was a failure, but it doesn't know why. The solution is to save the error that was logged (with virErrorPreserveLast() into the object the is used to share info between the threads, then we can set the error in the worker thread using virErrorRestore(). In the case of the error I was looking at, this changed the "unknown" message into: internal error: pcap_setfilter: can't remove kernel filter: Bad file descriptor Signed-off-by: NLaine Stump <laine@laine.org>
-
- 27 2月, 2018 2 次提交
-
-
由 Daniel P. Berrangé 提交于
The libvirt_storage_backend_sheepdog_priv.la library depends on symbols provided in the libvirt_driver_storage_impl.la library. As such the latter must be listed 2nd when passed to the linker to avoid symbol resolution problems. This mistake is being masked by the sheepdog driver linking in a second copy of the storage driver code. Remove this duplicate linkage of backend source and fix the test link order. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
A typo in the uninstall-data-extra rule expansion meant we just called the install rule again, instead of the uninstall rule. While fixing this, just inline the dependancy, since the intermediate install-data-extra rule adds no value. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 26 2月, 2018 7 次提交
-
-
由 Nikolay Shirokovskiy 提交于
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
由 Nikolay Shirokovskiy 提交于
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
由 Nikolay Shirokovskiy 提交于
Ensure all enum cases are listed in switch statements, or cast away enum type in places where we don't wish to cover all cases. Build is broken after 67966ad5 [1]. [1] m4: enforce that all enum cases are listed in switch statements Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
由 Nikolay Shirokovskiy 提交于
Build is broken by 5529b057 [1]. [1] cfg: forbid includes of headers in network and storage drivers again Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
由 Michal Privoznik 提交于
This partially reverts 82592551. When migrating a domain, qemuMigrationDstPrepareAny() is called which eventually calls qemuProcessLaunch(conn = NULL, flags = VIR_QEMU_PROCESS_START_AUTODESTROY); But the very first thing that qemuProcessLaunch does is check if AUTODESTROY flag is set and @conn is not NULL. Well, it is. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1494454 If a domain disk is stored on local filesystem (e.g. ext4) but is not being migrated it is very likely that domain is not able to run on destination. Regardless of share/cache mode. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 24 2月, 2018 1 次提交
-
-
由 Jim Fehlig 提交于
libxl requires the memory sizes to be rounded to 1MiB increments. Attempting to start a domain that violates this requirement will fail with the marginally helpful error 2018-02-22 01:55:32.921+0000: xc: panic: xc_dom_boot.c:141: xc_dom_boot_mem_init: can't allocate low memory for domain: Out of memory 2018-02-22 01:55:32.921+0000: libxl: libxl_dom.c:671:libxl__build_dom: xc_dom_boot_mem_init failed: No such file or directory Round the maximum and current memory values to the next 1MiB increment when generating the libxl_domain_config object. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
- 23 2月, 2018 19 次提交
-
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Jiri Denemark 提交于
Commit v3.7.0-14-gc57f3fd2 prevented adding a <boot order='x'/> element to an inactive domain with global <boot dev='...'/> element. However, as a result of that change updating any device with boot order would fail with 'boot order X is already used by another device', where "another device" is in fact the device which is being updated. To fix this we have to ignore the device which we're about to update when checking for boot order conflicts. https://bugzilla.redhat.com/show_bug.cgi?id=1546971Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
When calling virDomainDefCompatibleDevice to check a new device during device update, we need to pass the original device which is going to be updated in addition to the new device. Otherwise, the function can report false conflicts. The new argument is currently ignored by virDomainDefCompatibleDevice, but this will change in the following patch. https://bugzilla.redhat.com/show_bug.cgi?id=1546971Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-