[libvirt] [PATCH 0/4] Complete storage pool object privatization and use of RWLockable
by John Ferlan
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
6 years, 11 months
[libvirt] [RFC v2] arm64: KVM: KVM API extensions for SVE
by Dave Martin
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-s...
[2] Architecture spec
https://developer.arm.com/products/architecture/a-profile/docs/ddi0584/la...
---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
6 years, 11 months
[libvirt] [PATCH 0/6] Improvements to CPU frequency reporting
by Andrea Bolognani
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
6 years, 11 months
[libvirt] [PATCH v2 1/1] audit: Log only an info message if audit_level < 2 and audit is not supported
by Marc Hartmayer
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
6 years, 11 months
[libvirt] [PATCH v2] autogen.sh: tell user the correct make command
by Daniel P. Berrange
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
6 years, 11 months
[libvirt] [PATCH] audit: Log only an info message if audit_level < 2 and audit is not supported
by Marc Hartmayer
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
6 years, 11 months
[libvirt] [PATCH] virsh: fix typo s/node filters/network filters/
by Daniel P. Berrange
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
Pushed under trivial rule
tools/virsh-nwfilter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/virsh-nwfilter.c b/tools/virsh-nwfilter.c
index 0f64c446f3..40bc193ad5 100644
--- a/tools/virsh-nwfilter.c
+++ b/tools/virsh-nwfilter.c
@@ -272,7 +272,7 @@ virshNWFilterListCollect(vshControl *ctl,
}
/* there was an error during the call */
- vshError(ctl, "%s", _("Failed to list node filters"));
+ vshError(ctl, "%s", _("Failed to list network filters"));
goto cleanup;
--
2.14.3
6 years, 11 months
Re: [libvirt] [PATCH 12/12] qemu: block: add iSER support in qemu block type
by Peter Krempa
This is not a properly formatted patch. Please use git send-email for
submissions. Also read https://libvirt.org/hacking.html for coding style
guidelines ...
On Tue, Dec 12, 2017 at 16:53:48 +0800, zhangshengyu(a)fusionstack.cn wrote:
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index 66e21c4bd..c83ce5718 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -4554,6 +4554,11 @@ virDomainDeviceDefPostParseCommon(virDomainDeviceDefPtr dev,
> disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_ISCSI &&
> virDomainPostParseCheckISCSIPath(&disk->src->path) < 0)
> return -1;
> +
> + if (disk->src->type == VIR_STORAGE_TYPE_NETWORK &&
> + disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_ISER &&
> + virDomainPostParseCheckISCSIPath(&disk->src->path) < 0)
> + return -1;
... like how to format the code properly.
>
> if (disk->bus != VIR_DOMAIN_DISK_BUS_VIRTIO &&
> virDomainCheckVirtioOptions(disk->virtio) < 0)
> @@ -5160,7 +5165,8 @@ virDomainDiskDefValidate(const virDomainDiskDef *disk)
> if (!(disk->src->type == VIR_STORAGE_TYPE_BLOCK ||
> disk->src->type == VIR_STORAGE_TYPE_VOLUME ||
> (disk->src->type == VIR_STORAGE_TYPE_NETWORK &&
> - disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_ISCSI))) {
> + (disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_ISCSI ||
> + disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_ISER)))) {
> virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> _("disk '%s' improperly configured for a "
> "device='lun'"), disk->dst);
> diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c
> index 585f0255e..a9543293d 100644
> --- a/src/qemu/qemu_block.c
> +++ b/src/qemu/qemu_block.c
> @@ -831,7 +831,7 @@ qemuBlockStorageSourceGetISCSIProps(virStorageSourcePtr src)
> "s:portal", portal,
> "s:target", target,
> "u:lun", lun,
> - "s:transport", "tcp",
> + "s:transport", src->protocol == VIR_STORAGE_NET_PROTOCOL_ISER? "iser":"tcp",
too long line.
> "S:user", username,
> "S:password-secret", objalias,
> NULL));
> @@ -1030,6 +1030,7 @@ qemuBlockStorageSourceGetBackendProps(virStorageSourcePtr src)
> break;
>
> case VIR_STORAGE_NET_PROTOCOL_ISCSI:
> + case VIR_STORAGE_NET_PROTOCOL_ISER:
Is it really a new protocol? Isn't it just a variation of ISCSI. Qemu
treats it as a variation.
> if (!(fileprops = qemuBlockStorageSourceGetISCSIProps(src)))
> return NULL;
> break;
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index d7150cae1..76b2a6cc9 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -8133,7 +8133,7 @@ int
> qemuDomainDefValidateDiskLunSource(const virStorageSource *src)
> {
> if (virStorageSourceGetActualType(src) == VIR_STORAGE_TYPE_NETWORK) {
> - if (src->protocol != VIR_STORAGE_NET_PROTOCOL_ISCSI) {
> + if (src->protocol != VIR_STORAGE_NET_PROTOCOL_ISCSI && src->protocol != VIR_STORAGE_NET_PROTOCOL_ISER) {
> virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> _("disk device='lun' is not supported "
> "for protocol='%s'"),
[...]
> diff --git a/src/qemu/qemu_parse_command.c b/src/qemu/qemu_parse_command.c
> index 5fe3f97d0..72e137ce4 100644
> --- a/src/qemu/qemu_parse_command.c
> +++ b/src/qemu/qemu_parse_command.c
> @@ -709,6 +709,12 @@ qemuParseCommandLineDisk(virDomainXMLOptionPtr xmlopt,
>
> if (qemuParseISCSIString(def) < 0)
> goto error;
> + } else if (STRPREFIX(def->src->path, "iser:")) {
> + def->src->type = VIR_STORAGE_TYPE_NETWORK;
> + def->src->protocol = VIR_STORAGE_NET_PROTOCOL_ISER;
> +
> + if (qemuParseISCSIString(def) < 0)
> + goto error;
> } else if (STRPREFIX(def->src->path, "sheepdog:")) {
> char *p = def->src->path;
> char *port, *vdi;
> @@ -2157,6 +2163,7 @@ qemuParseCommandLine(virCapsPtr caps,
> goto error;
>
> break;
> + case VIR_STORAGE_NET_PROTOCOL_ISER:
> case VIR_STORAGE_NET_PROTOCOL_ISCSI:
> if (qemuParseISCSIString(disk) < 0)
> goto error;
> diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
> index 6594715e5..cf5c2904e 100644
> --- a/src/util/virstoragefile.c
> +++ b/src/util/virstoragefile.c
[...]
> @@ -3295,6 +3368,7 @@ static const struct virStorageSourceJSONDriverParser jsonParsers[] = {
> {"tftp", virStorageSourceParseBackingJSONUri, VIR_STORAGE_NET_PROTOCOL_TFTP},
> {"gluster", virStorageSourceParseBackingJSONGluster, 0},
> {"iscsi", virStorageSourceParseBackingJSONiSCSI, 0},
> + {"iser", virStorageSourceParseBackingJSONiSER, 0},
So this is plain wrong. In qemu it's stil protocol called 'iscsi' with
a transport of 'iser', not a completely new protocol.
citation from qemu.git/qmp/block-core.json:
##
# @IscsiTransport:
#
# An enumeration of libiscsi transport types
#
# Since: 2.9
##
{ 'enum': 'IscsiTransport',
'data': [ 'tcp', 'iser' ] }
##
# @IscsiHeaderDigest:
#
# An enumeration of header digests supported by libiscsi
#
# Since: 2.9
##
{ 'enum': 'IscsiHeaderDigest',
'prefix': 'QAPI_ISCSI_HEADER_DIGEST',
'data': [ 'crc32c', 'none', 'crc32c-none', 'none-crc32c' ] }
##
# @BlockdevOptionsIscsi:
#
# @transport: The iscsi transport type
#
# @portal: The address of the iscsi portal
#
# @target: The target iqn name
#
# @lun: LUN to connect to. Defaults to 0.
#
# @user: User name to log in with. If omitted, no CHAP
# authentication is performed.
#
# @password-secret: The ID of a QCryptoSecret object providing
# the password for the login. This option is required if
# @user is specified.
#
# @initiator-name: The iqn name we want to identify to the target
# as. If this option is not specified, an initiator name is
# generated automatically.
#
# @header-digest: The desired header digest. Defaults to
# none-crc32c.
#
# @timeout: Timeout in seconds after which a request will
# timeout. 0 means no timeout and is the default.
#
# Driver specific block device options for iscsi
#
# Since: 2.9
##
{ 'struct': 'BlockdevOptionsIscsi',
'data': { 'transport': 'IscsiTransport',
'portal': 'str',
'target': 'str',
'*lun': 'int',
'*user': 'str',
'*password-secret': 'str',
'*initiator-name': 'str',
'*header-digest': 'IscsiHeaderDigest',
'*timeout': 'int' } }
Also it's missing a test case.
> {"nbd", virStorageSourceParseBackingJSONNbd, 0},
> {"sheepdog", virStorageSourceParseBackingJSONSheepdog, 0},
> {"ssh", virStorageSourceParseBackingJSONSSH, 0},
I don't object to adding iser transport per-se, but this patch is a
mess. It's missing proper commit message and the protocol is not a new
protocol but rather a different transport for ISCSI. Please follow the
contributor guidelines before submitting a new patch.
Also please add a case to the qemuxml2argv test so that this addition is
tested properly as I suspect that iser would work only if you enable
authentication in current libvirt since you did not tweak
qemuDiskSourceNeedsProps
Peter
6 years, 11 months
[libvirt] [PATCH 0/3] Couple of mem leak fixes
by Michal Privoznik
*** BLURB HERE ***
Michal Privoznik (3):
xenParseXLVnuma: Don't leak @tmp and @token
xenMakeIPList: Don't leak @address_array
fillQemuCaps: Don't leak machine string
src/xenconfig/xen_common.c | 1 +
src/xenconfig/xen_xl.c | 2 ++
tests/domaincapstest.c | 10 ++++++----
3 files changed, 9 insertions(+), 4 deletions(-)
--
2.13.6
6 years, 11 months
