- Devel - libvirt List Archives

[libvirt] [PATCH 0/1] *** Add iSER block type supported in qemu ***
by lichstor＠gmail.com 14 Dec '17

14 Dec '17

From: zhangshengyu <zhangshengyu(a)fusionstack.cn> *** Add iSER block type supported in qemu *** zhangshengyu (1): add support for iSER block type. src/conf/domain_conf.c | 8 ++++- src/qemu/qemu_block.c | 3 +- src/qemu/qemu_command.c | 3 +- src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_driver.c | 3 ++ src/qemu/qemu_parse_command.c | 7 ++++ src/util/virstoragefile.c | 75 +++++++++++++++++++++++++++++++++++++++++++ src/util/virstoragefile.h | 1 + 8 files changed, 98 insertions(+), 4 deletions(-) -- 2.13.6 (Apple Git-96)

3 6

[libvirt] [PATCH 0/2] Fix a couple small networking bugs
by Laine Stump 14 Dec '17

14 Dec '17

Laine Stump (2): qemu: delete exist bandwidth restrictions when they are removed from config qemu: log error on attempts to set filterref on an OVS-connected interface src/qemu/qemu_command.c | 28 +++++++++++++++++++--------- src/qemu/qemu_hotplug.c | 18 +++++++++++++----- 2 files changed, 32 insertions(+), 14 deletions(-) -- 2.13.6

2 4

[libvirt] [PATCH] docs: Fix news.xml syntax
by John Ferlan 14 Dec '17

14 Dec '17

Commit id '1241e487' used <code><interface></code> which is not valid syntax for a <summary>. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- Pushed under build breaker rule as CI libvirt-master-check was failing docs/news.xml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/news.xml b/docs/news.xml index 7509416ec..bb611b7ba 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -39,8 +39,7 @@ <section title="Improvements"> <change> <summary> - Xen: Add support for multiple IP addresses on - <code><interface></code> devices + Xen: Add support for multiple IP addresses on interface devices </summary> </change> </section> -- 2.13.6

1 0

[libvirt] [PATCH] xenconfig: fix issues found by coverity in multiple IP support
by Marek Marczykowski-Górecki 13 Dec '17

13 Dec '17

- virStringSplit may return NULL - VIR_ALLOC_N initialize the array already Cc: John Ferlan <jferlan(a)redhat.com> Signed-off-by: Marek Marczykowski-Górecki <marmarek(a)invisiblethingslab.com> --- src/xenconfig/xen_common.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c index ff0df5fb7..ca3b4dee6 100644 --- a/src/xenconfig/xen_common.c +++ b/src/xenconfig/xen_common.c @@ -968,6 +968,9 @@ xenParseVif(virConfPtr conf, virDomainDefPtr def, const char *vif_typename) char **ip_list = virStringSplit(ip, " ", 0); size_t i; + if (!ip_list) + goto cleanup; + for (i = 0; ip_list[i]; i++) { if (virDomainNetAppendIPAddress(net, ip_list[i], 0, 0) < 0) { virStringListFree(ip_list); @@ -1191,8 +1194,6 @@ xenMakeIPList(virNetDevIPInfoPtr guestIP) if (!address_array[i]) goto cleanup; } - address_array[guestIP->nips] = NULL; - ret = virStringListJoin((const char**)address_array, " "); cleanup: -- 2.13.6

2 1

[libvirt] [PATCH 0/4] Complete storage pool object privatization and use of RWLockable
by John Ferlan 13 Dec '17

13 Dec '17

After this series the storage pool will be private to virstorageobj and will be a self locking list of hash tables similar to other drivers. All that remains will be to make the storage volume lists be hash tables, but that's only once this is accepted. First patch is related to review comment from last series. John Ferlan (4): storage: Fix path check in storagePoolLookupByTargetPath storage: Privatize virStoragePoolObjListPtr storage: Convert virStoragePoolObjList to use virObjectRWLockable storage: Reduce need for using storageDriverLock src/conf/virstorageobj.c | 649 ++++++++++++++++++++++++++++++------------- src/conf/virstorageobj.h | 12 +- src/libvirt_private.syms | 2 +- src/storage/storage_driver.c | 180 +++++------- src/test/test_driver.c | 51 ++-- 5 files changed, 545 insertions(+), 349 deletions(-) -- 2.13.6

2 8

[libvirt] [RFC v2] arm64: KVM: KVM API extensions for SVE
by Dave Martin 13 Dec '17

13 Dec '17

Hi all, Here's a second, slightly more complete stab at the KVM API extensions for SVE. I haven't started implementing in earnest yet, so any comments at this stage would be very helpful. [libvir-list readers: this is a proposal for extending the KVM API on AArch64 systems to support the Scalable Vector Extension [1], [2]. This has some interesting configuration and migration quirks -- see "Vector length control" in particular, and feel free to throw questions my way...] Cheers ---Dave [1] Overview https://community.arm.com/processors/b/blog/posts/technology-update-the-sca… [2] Architecture spec https://developer.arm.com/products/architecture/a-profile/docs/ddi0584/late… ---8<--- New feature KVM_ARM_VCPU_SVE: * enables exposure of SVE to the guest * enables visibility of / access to KVM_REG_ARM_SVE_*() via KVM reg ioctls. The main purposes of this are a) is to allow userspace to hide weird-sized registers that it doesn't understand how to deal with, and b) allow SVE to be hidden from the VM so that it can migrate to nodes that don't support SVE. ZCR_EL1 is not specifically hidden, since it is "just a system register" and does not have a weird size or semantics etc. Registers: * A new register size is defined KVM_REG_SIZE_U2048 (which can be encoded sensibly using the next unused value for the reg size field in the reg ID) (grep KVM_REG_SIZE_). * Reg IDs for the SVE regs will be defined as "coproc" 0x14 (i.e., 0x14 << KVM_REG_ARM_COPROC_SHIFT) KVM_REG_ARM_SVE_Z(n, i) is slice i of Zn (each slice is 2048 bits) KVM_REG_ARM_SVE_P(n, i) is slice i of Pn (each slice is 256 bits) KVM_REG_ARM_FFR(i) is slice i of FFR (each slice is 256 bits) The slice sizes allow each register to be read/written in exactly one slice for SVE. Surplus bits (beyond the maximum VL supported by the vcpu) will be read-as-zero write-ignore. Reading/writing surplus slices will probably be forbidden, and the surplus slices would not be reported via KVM_GET_REG_LIST. (We could make these RAZ/WI too, but I'm not sure if it's worth it, or why it would be useful.) Future extensions to the architecture might grow the registers up to 32 slices: this may or may not actually happen, but SVE keeps the possibilty open. I've tried to design for it. * KVM_REG_ARM_SVE_Z(n, 0) bits [127:0] alias Vn in KVM_REG_ARM_CORE(fp_regs.v[n]) .. KVM_REG_ARM_CORE(fp_regs.v[n])+3. It's simplest for userspace if the two views always appear to be in sync, but it's unclear whether this is really useful. Perhaps this can be relaxed if it's a big deal for the KVM implementation; I don't know yet. Vector length control: Some means is needed to determine the set of vector lengths visible to guest software running on a vcpu. When a vcpu is created, the set would be defaulted to the maximal set that can be supported while permitting each vcpu to run on any host CPU. SVE has some virtualisation quirks which mean that this set may exclude some vector lengths that are available for host userspace applications. The common case should be that the sets are the same however. * New ioctl KVM_ARM_VCPU_{SET,GET}_SVE_VLS to set or retrieve the set of vector lengths available to the guest. Adding random vcpu ioctls To configure a non-default set of vector lengths, KVM_ARM_VCPU_SET_SVE_VLS can be called: this would only be permitted before the vcpu is first run. This is primarily intended for supporting migration, by providing a robust check that the destination node will run the vcpu correctly. In a cluster with non-uniform SVE implementation across nodes, this also allows a specific set of VLs to be requested that the caller knows is usable across the whole cluster. For migration purposes, userspace would need to do KVM_ARM_VCPU_GET_SVE_VLS at the origin node and store the returned set as VM metadata: on the destination node, KVM_ARM_VCPU_SET_SVE_VLS should be used to request that exact set of VLs: if the destination node can't support that set of VLs, the call will fail. The interface would look something like: ioctl(vcpu_fd, KVM_ARM_SVE_SET_VLS, __u64 vqs[SVE_VQ_MAX / 64]); How to expose this to the user in an intelligible way would be a problem for userspace to solve. At present, other than initialising each vcpu to the maximum supportable set of VLs, I don't propose having a way to probe for what sets of VLs are supportable: the above call either succeeds or fails. Cheers ---Dave

2 2

[libvirt] [PATCH 0/6] Improvements to CPU frequency reporting
by Andrea Bolognani 13 Dec '17

13 Dec '17

A few steps towards eventually fixing https://bugzilla.redhat.com/show_bug.cgi?id=1206353 The commit message for patch 6/6 contains most of the rationale, previous patches are cleanups. If not for the new test case added with patch 1/6, the overall diffstat would be negative. Andrea Bolognani (6): tests: Add host CPU data for Moonshot (RHEL 7.4) util: Introduce virHostCPUGetInfoParseCPUInfo() util: Introduce virHostCPUGetInfoParseCPUFrequency() util: Tweak virHostCPUGetInfoParseCPUFrequency() util: Tweak s390(x) case for CPU frequency util: Don't report CPU frequency for ARM hosts src/util/virhostcpu.c | 151 ++++++++++----------- .../linux-aarch64-rhel74-moonshot.cpuinfo | 72 ++++++++++ .../linux-aarch64-rhel74-moonshot.expected | 1 + .../linux-armv6l-raspberrypi.expected | 2 +- .../linux-rhel74-moonshot/cpu/cpu0/node0 | 1 + .../linux-rhel74-moonshot/cpu/cpu0/online | 1 + .../cpu/cpu0/topology/core_id | 1 + .../cpu/cpu0/topology/core_siblings | 1 + .../cpu/cpu0/topology/core_siblings_list | 1 + .../cpu/cpu0/topology/physical_package_id | 1 + .../cpu/cpu0/topology/thread_siblings | 1 + .../cpu/cpu0/topology/thread_siblings_list | 1 + .../linux-rhel74-moonshot/cpu/cpu1/node0 | 1 + .../linux-rhel74-moonshot/cpu/cpu1/online | 1 + .../cpu/cpu1/topology/core_id | 1 + .../cpu/cpu1/topology/core_siblings | 1 + .../cpu/cpu1/topology/core_siblings_list | 1 + .../cpu/cpu1/topology/physical_package_id | 1 + .../cpu/cpu1/topology/thread_siblings | 1 + .../cpu/cpu1/topology/thread_siblings_list | 1 + .../linux-rhel74-moonshot/cpu/cpu2/node0 | 1 + .../linux-rhel74-moonshot/cpu/cpu2/online | 1 + .../cpu/cpu2/topology/core_id | 1 + .../cpu/cpu2/topology/core_siblings | 1 + .../cpu/cpu2/topology/core_siblings_list | 1 + .../cpu/cpu2/topology/physical_package_id | 1 + .../cpu/cpu2/topology/thread_siblings | 1 + .../cpu/cpu2/topology/thread_siblings_list | 1 + .../linux-rhel74-moonshot/cpu/cpu3/node0 | 1 + .../linux-rhel74-moonshot/cpu/cpu3/online | 1 + .../cpu/cpu3/topology/core_id | 1 + .../cpu/cpu3/topology/core_siblings | 1 + .../cpu/cpu3/topology/core_siblings_list | 1 + .../cpu/cpu3/topology/physical_package_id | 1 + .../cpu/cpu3/topology/thread_siblings | 1 + .../cpu/cpu3/topology/thread_siblings_list | 1 + .../linux-rhel74-moonshot/cpu/cpu4/node0 | 1 + .../linux-rhel74-moonshot/cpu/cpu4/online | 1 + .../cpu/cpu4/topology/core_id | 1 + .../cpu/cpu4/topology/core_siblings | 1 + .../cpu/cpu4/topology/core_siblings_list | 1 + .../cpu/cpu4/topology/physical_package_id | 1 + .../cpu/cpu4/topology/thread_siblings | 1 + .../cpu/cpu4/topology/thread_siblings_list | 1 + .../linux-rhel74-moonshot/cpu/cpu5/node0 | 1 + .../linux-rhel74-moonshot/cpu/cpu5/online | 1 + .../cpu/cpu5/topology/core_id | 1 + .../cpu/cpu5/topology/core_siblings | 1 + .../cpu/cpu5/topology/core_siblings_list | 1 + .../cpu/cpu5/topology/physical_package_id | 1 + .../cpu/cpu5/topology/thread_siblings | 1 + .../cpu/cpu5/topology/thread_siblings_list | 1 + .../linux-rhel74-moonshot/cpu/cpu6/node0 | 1 + .../linux-rhel74-moonshot/cpu/cpu6/online | 1 + .../cpu/cpu6/topology/core_id | 1 + .../cpu/cpu6/topology/core_siblings | 1 + .../cpu/cpu6/topology/core_siblings_list | 1 + .../cpu/cpu6/topology/physical_package_id | 1 + .../cpu/cpu6/topology/thread_siblings | 1 + .../cpu/cpu6/topology/thread_siblings_list | 1 + .../linux-rhel74-moonshot/cpu/cpu7/node0 | 1 + .../linux-rhel74-moonshot/cpu/cpu7/online | 1 + .../cpu/cpu7/topology/core_id | 1 + .../cpu/cpu7/topology/core_siblings | 1 + .../cpu/cpu7/topology/core_siblings_list | 1 + .../cpu/cpu7/topology/physical_package_id | 1 + .../cpu/cpu7/topology/thread_siblings | 1 + .../cpu/cpu7/topology/thread_siblings_list | 1 + .../linux-rhel74-moonshot/cpu/kernel_max | 1 + .../linux-rhel74-moonshot/cpu/offline | 1 + .../linux-rhel74-moonshot/cpu/online | 1 + .../linux-rhel74-moonshot/cpu/possible | 1 + .../linux-rhel74-moonshot/cpu/present | 1 + .../linux-rhel74-moonshot/node/has_cpu | 1 + .../linux-rhel74-moonshot/node/has_memory | 1 + .../linux-rhel74-moonshot/node/has_normal_memory | 1 + .../linux-rhel74-moonshot/node/node0/cpu0 | 1 + .../linux-rhel74-moonshot/node/node0/cpu1 | 1 + .../linux-rhel74-moonshot/node/node0/cpu2 | 1 + .../linux-rhel74-moonshot/node/node0/cpu3 | 1 + .../linux-rhel74-moonshot/node/node0/cpu4 | 1 + .../linux-rhel74-moonshot/node/node0/cpu5 | 1 + .../linux-rhel74-moonshot/node/node0/cpu6 | 1 + .../linux-rhel74-moonshot/node/node0/cpu7 | 1 + .../linux-rhel74-moonshot/node/node0/cpulist | 1 + .../linux-rhel74-moonshot/node/node0/cpumap | 1 + .../linux-rhel74-moonshot/node/online | 1 + .../linux-rhel74-moonshot/node/possible | 1 + tests/virhostcputest.c | 1 + 89 files changed, 230 insertions(+), 81 deletions(-) create mode 100644 tests/virhostcpudata/linux-aarch64-rhel74-moonshot.cpuinfo create mode 100644 tests/virhostcpudata/linux-aarch64-rhel74-moonshot.expected create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu0/node0 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu0/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu0/topology/core_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu0/topology/core_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu0/topology/core_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu0/topology/physical_package_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu0/topology/thread_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu0/topology/thread_siblings_list create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu1/node0 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu1/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu1/topology/core_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu1/topology/core_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu1/topology/core_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu1/topology/physical_package_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu1/topology/thread_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu1/topology/thread_siblings_list create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu2/node0 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu2/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu2/topology/core_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu2/topology/core_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu2/topology/core_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu2/topology/physical_package_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu2/topology/thread_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu2/topology/thread_siblings_list create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu3/node0 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu3/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu3/topology/core_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu3/topology/core_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu3/topology/core_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu3/topology/physical_package_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu3/topology/thread_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu3/topology/thread_siblings_list create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu4/node0 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu4/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu4/topology/core_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu4/topology/core_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu4/topology/core_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu4/topology/physical_package_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu4/topology/thread_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu4/topology/thread_siblings_list create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu5/node0 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu5/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu5/topology/core_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu5/topology/core_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu5/topology/core_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu5/topology/physical_package_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu5/topology/thread_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu5/topology/thread_siblings_list create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu6/node0 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu6/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu6/topology/core_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu6/topology/core_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu6/topology/core_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu6/topology/physical_package_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu6/topology/thread_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu6/topology/thread_siblings_list create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu7/node0 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu7/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu7/topology/core_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu7/topology/core_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu7/topology/core_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu7/topology/physical_package_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu7/topology/thread_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu7/topology/thread_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/kernel_max create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/offline create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/possible create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/present create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/node/has_cpu create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/node/has_memory create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/node/has_normal_memory create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpu0 create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpu1 create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpu2 create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpu3 create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpu4 create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpu5 create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpu6 create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpu7 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpulist create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpumap create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/node/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/node/possible -- 2.14.3

3 20

[libvirt] [PATCH v2 1/1] audit: Log only an info message if audit_level < 2 and audit is not supported
by Marc Hartmayer 13 Dec '17

13 Dec '17

Replace the error message during startup of libvirtd with an info message if audit_level < 2 and audit is not supported by the kernel. Audit is not supported by the current kernel if the kernel does not have audit compiled in or if audit is disabled (e.g. by the kernel cmdline). Signed-off-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com> --- daemon/libvirtd.c | 2 +- src/util/viraudit.c | 16 ++++++++++++++-- src/util/viraudit.h | 2 +- 3 files changed, 16 insertions(+), 4 deletions(-) diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c index 5103e8debea6..6d3b83355bca 100644 --- a/daemon/libvirtd.c +++ b/daemon/libvirtd.c @@ -1422,7 +1422,7 @@ int main(int argc, char **argv) { if (config->audit_level) { VIR_DEBUG("Attempting to configure auditing subsystem"); - if (virAuditOpen() < 0) { + if (virAuditOpen(config->audit_level) < 0) { if (config->audit_level > 1) { ret = VIR_DAEMON_ERR_AUDIT; goto cleanup; diff --git a/src/util/viraudit.c b/src/util/viraudit.c index 17e58b3a9574..3c444b69ab9f 100644 --- a/src/util/viraudit.c +++ b/src/util/viraudit.c @@ -55,11 +55,23 @@ static int auditfd = -1; #endif static bool auditlog; -int virAuditOpen(void) +int virAuditOpen(ATTRIBUTE_UNUSED unsigned int audit_level) { #if WITH_AUDIT if ((auditfd = audit_open()) < 0) { - virReportSystemError(errno, "%s", _("Unable to initialize audit layer")); + /* You get these error codes only when the kernel does not + * have audit compiled in or it's disabled (e.g. by the kernel + * cmdline) */ + if (errno == EINVAL || errno == EPROTONOSUPPORT || + errno == EAFNOSUPPORT) { + if (audit_level < 2) + VIR_INFO("Audit is not supported by the kernel"); + else + virReportError(VIR_FROM_THIS, "%s", _("Audit is not supported by the kernel")); + } else { + virReportSystemError(errno, "%s", _("Unable to initialize audit layer")); + } + return -1; } diff --git a/src/util/viraudit.h b/src/util/viraudit.h index ed3d66ab5d0f..478dc8408f4e 100644 --- a/src/util/viraudit.h +++ b/src/util/viraudit.h @@ -32,7 +32,7 @@ typedef enum { VIR_AUDIT_RECORD_RESOURCE, } virAuditRecordType; -int virAuditOpen(void); +int virAuditOpen(unsigned int audit_level); void virAuditLog(bool enabled); -- 2.13.4

2 2

[libvirt] [PATCH v2] autogen.sh: tell user the correct make command
by Daniel P. Berrange 13 Dec '17

13 Dec '17

When autogen.sh finishes it helpfully prints "Now type 'make' to compile libvirt." which is fine if on a host with GNU make, but on *BSD running 'make' will end in tears. We should tell users to run 'gmake' on these platforms. If 'gmake' doesn't exist then we should report an error too "GNU make is required to build libvirt" Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- autogen.sh | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/autogen.sh b/autogen.sh index d5d836aa71..ea94528de6 100755 --- a/autogen.sh +++ b/autogen.sh @@ -175,6 +175,18 @@ if test "$OBJ_DIR"; then } fi +# Make sure we can find GNU make and tell the user +# the right command to run +if make -v 2>&1 | grep -q "GNU Make"; then + MAKE=make +else + if which gmake >/dev/null 2>&1; then + MAKE=gmake + else + die "GNU make is required to build libvirt" + fi +fi + if test -z "$*" && test -z "$extra_args" && test -f config.status; then echo "Running config.status..." ./config.status --recheck || { @@ -193,4 +205,4 @@ else fi echo -echo "Now type 'make' to compile libvirt." +echo "Now type '$MAKE' to compile libvirt." -- 2.14.3

2 2

[libvirt] [PATCH] audit: Log only an info message if audit_level < 2 and audit is not supported
by Marc Hartmayer 13 Dec '17

13 Dec '17

Replace the error message during startup of libvirtd with an info message if audit_level < 2 and audit is not supported by the kernel. Audit is not supported by the current kernel if the kernel does not have audit compiled in or if audit is disabled (e.g. by the kernel cmdline). Signed-off-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com> --- daemon/libvirtd.c | 2 +- src/util/viraudit.c | 17 +++++++++++++++-- src/util/viraudit.h | 2 +- 3 files changed, 17 insertions(+), 4 deletions(-) diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c index 589b32192e3d..6bbff0d45684 100644 --- a/daemon/libvirtd.c +++ b/daemon/libvirtd.c @@ -1418,7 +1418,7 @@ int main(int argc, char **argv) { if (config->audit_level) { VIR_DEBUG("Attempting to configure auditing subsystem"); - if (virAuditOpen() < 0) { + if (virAuditOpen(config->audit_level) < 0) { if (config->audit_level > 1) { ret = VIR_DAEMON_ERR_AUDIT; goto cleanup; diff --git a/src/util/viraudit.c b/src/util/viraudit.c index 17e58b3a9574..9b755e384f24 100644 --- a/src/util/viraudit.c +++ b/src/util/viraudit.c @@ -55,11 +55,24 @@ static int auditfd = -1; #endif static bool auditlog; -int virAuditOpen(void) +int virAuditOpen(unsigned int audit_level) { #if WITH_AUDIT if ((auditfd = audit_open()) < 0) { - virReportSystemError(errno, "%s", _("Unable to initialize audit layer")); + /* You get these error codes only when the kernel does not + * have audit compiled in or it's disabled (e.g. by the kernel + * cmdline) */ + if (errno == EINVAL || errno == EPROTONOSUPPORT || + errno == EAFNOSUPPORT) { + const char msg[] = "Audit is not supported by the kernel"; + if (audit_level < 2) + VIR_INFO("%s", _(msg)); + else + virReportError(VIR_FROM_THIS, "%s", _(msg)); + } else { + virReportSystemError(errno, "%s", _("Unable to initialize audit layer")); + } + return -1; } diff --git a/src/util/viraudit.h b/src/util/viraudit.h index edaddf3c886f..e0471be1a85d 100644 --- a/src/util/viraudit.h +++ b/src/util/viraudit.h @@ -32,7 +32,7 @@ typedef enum { VIR_AUDIT_RECORD_RESOURCE, } virAuditRecordType; -int virAuditOpen(void); +int virAuditOpen(unsigned int audit_level); void virAuditLog(bool enabled); -- 2.13.4

2 5